System and method for verification, authentication, and notification of a transaction

ABSTRACT

A system and method for verifying, authenticating, and providing notification of a transaction, such as a commercial or financial transaction, with and/or to at least one party identified as engaging in the transaction and/or identified as having a potential interest in the transaction or type of transaction, are provided. A central system accepts information regarding a transaction, including information about at least one party identified as engaging in the transaction, such as by a credit account number or Social Security number or merchant account number, and/or identified as having a potential interest in the transaction. Based on the information regarding the transaction and any supplemental information the central system determines, the central system communicates with and/or to at least one party and/or additional or alternative parties, via at least one communications device or system having a communications address, such as a telephone number or Short Message Service address, predetermined as belonging to the at least one party and/or additional or alternative parties. Via said communications, at least one party having an interest or a potential interest in the transaction may be notified of it, and may further be enabled or required to supply additional verifying or authenticating information to the central system. If the transaction was initiated or engaged in via a communications link, such as via the Internet, said communications preferably occur over at least one different communications link and/or protocol, such as via a wireless voice network. The central system may then compute a result based on the outcomes of said communications, and may then transmit the result to the user and/or to a second system or device.

PARENT CASE TEXT

[0001] This application claims the benefit of U.S. Provisional No.60/354,275 with filing date Feb. 4, 2002.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] The invention relates to fraud prevention and fraud “earlywarning” notifications for transactions, in particular remote and/orelectronic transactions such as “e-commerce” and “m-commerce”transactions wherein it is desirable to authenticate and verify one ormore parties' identities and intentions before the transaction isconcluded and/or to notify one or more parties of the occurrence of thetransaction.

[0004] 2. Description of the Related Art

[0005] In a transaction in which security is a concern, such as anelectronically conducted transaction involving a funds transfer or apurchase or payment, there are three basic questions which must besatisfied:

[0006] 1. Are the parties to the transaction who they say they are? (Dothey own the goods, services, or funds or financial accounts that theyrepresent they do?)

[0007] 2. Do they have the necessary authority or authorization toapprove the transaction?

[0008] 3. Is the environment in which the transaction occurs secure?That is, can other parties gain access to the private information beingexchanged during such a transaction?

[0009] Regarding question 1, the payments industry has devotedconsiderable attention to methods and systems designed to a) verify theidentity of a purchaser, b) assess the risk of any given transaction,and c) take follow-on action in high-risk cases, either by subsequentlyinquiring of the payer whether the transaction was proper, or by denyingfunds or credit at the time of the transaction subject to later manualcontact with the payer.

[0010] For more complex or higher-value transactions, per question 2 abuyer may be subject to a set of audit and control procedures designedto limit his/her purchasing authority. In most consumer purchasingcases, the buyer and authority-holder are usually the same person. Inmany organizational purchasing situations, the buyer(s) andauthority-holder(s) are not the same. The payments industry has oneprimary tool for limiting purchasing authority, which is the spendinglimit or credit limit associated with the buyer's account. Attemptedsolutions to question 1 also help address question 2, since verifyingidentity helps address cases wherein a buyer is suborning the purchasingauthority of another party by use of a stolen credit card number orother private information.

[0011] As regards question 3, the most relatively secure environment forpurchase transactions remains a merchant's store, in which a buyer andseller can interact face to face, multiple forms of identification canbe reviewed, and the opportunities for theft of private information aregenerally limited. At the other extreme are telephone, mail, andelectronic commerce, in which the buyer is represented merely by his/heraccount information as supplied by phone, on a mailed form, or by dataentry via a computer or other electronic device. Here, the opportunitiesfor fraud and the theft of private information are relatively high.Further, there is a prevailing public perception that electronicpurchasing environments (for example, virtual storefronts or Internetauctions) are inherently insecure in regard to the transmission and/orstorage of private information.

[0012] The above factors are reflected in the relative “discount rate”(price) charged to merchants by credit card processors for in-storetransactions vs. “card not present” transactions, for example.Typically, merchants pay 60% more per sales dollar in a “card notpresent” transaction than when a credit card is physically presented forswiping.

[0013] These differences in risk also apply when accounts themselves areopened, closed, and modified remotely, as via mail, telephone, wire, orother electronic means.

[0014] Current transaction-verification systems and methods, such as forcredit, debit, and purchase-card purchases and payments, AutomatedTeller Machine (ATM) interactions, e-ticket redemption, and the like,may be grouped into four broad categories: 1) physical identification ofthe purchasing party or of a difficult-to-mimic characteristic of thepurchasing party, such as by signature comparison or biometric scanning,2) data entry of passwords or other identification codes, such as thePersonal Identification Number (PIN) codes used with ATMs and callingcards, 3) validation of embedded digital authenticating information,such as is found in “smart cards”, and 4) verifying private knowledgepresumed known only to the account holder, such as the account holder'sbilling address or Social Security Number (SSN), prior to approving atransaction, including opening, closing, and modifying an account. Afifth category, devoted to limiting the exposure of sensitive privateinformation such as credit card numbers to insecure or weakly secureenvironments subject to high levels of electronic theft or hacking, suchas the Internet, is the substitution of dummy information for the actualprivate information, which dummy information is reconciled with theactual private information after its receipt by the payment processingorganization.

[0015] Additional systems and methods have been employed by creditreporting agencies, which agencies already monitor the status ofindividuals' credit accounts. Such organizations may offer theircustomers regular monthly communications by mail or electronic mailidentifying new accounts established in the customer's name or with thecustomer's federal tax identification number since the last suchcommunication.

[0016] Especially in categories (2) (3) and (4) above, transactionapproval by a bank or other merchant processing or payment processingorganization or network is often coupled with an automated riskdetection processes and human follow-up, as when a credit card issuer'srisk assessment system determines that an unexpectedly large,out-of-state purchase is “high risk” for a given account holder, andthen provides that information to a customer service representative whomay call the account holder's telephone to attempt to confirm thetransaction's validity, typically after the fact, or to leave a messagefor the account holder that the card account is suspended pending theaccount holder's reply. It is often the case that the account holder'sability to judge what constitutes a fraudulent transaction conducted inhis/her name considerably exceeds that of said risk assessment systemand customer service representative. Despite this judgment-gap, today'saccount holders have, at best, only after-the-fact means available tothem from their financial institutions, or from merchants, to audittransactions occurring in their name, including the opening, closing,and modification of accounts, or at-the-time means which involvesignificant new technologies and new processes to implement, learn, anduse. In some cases the burden of implementing, learning and using fallson the merchant or other provider of goods, services, or funds, as wellas the account holder.

[0017] Merchants subjected to fraudulent transactions are informed afterthe fact as well, when the true account holder disputes a transactionwith his/her payments organization. In the case of credit cardtransactions, the merchant is then charged back for the value of thedisputed transaction and may also be charged a dispute investigationfee, resulting in a loss of profits and goods.

[0018] Additional research and development in the payments industry hasfocused on adding encrypted identifying codes or digital certificates tocredit cards via an embedded microprocessor (as in “smart cards”) or viasoftware on a personal computer (“e-wallets”); and on physicallyprinting unique numeric identification numbers or numeric passwords(such as CVV2/CVC2/CID codes) on credit cards. Said codes are arelatively recent security feature for use in “card-not-present”transactions and now appear on, for example, Visa, MasterCard, AmericanExpress and Discover cards. As of this writing, these codes arecomprised of a three- or four-digit number which provides acryptographic check of the information embossed on the card, called CVV2(Visa, 3-digit), CVC2 (MasterCard, 3-digit), and CID (American Express,4-digit, and Discover, 3-digit). These code values help validate twothings: a) the customer has the physical credit card in his/herpossession, and b) the card account is legitimate. CVV2/CVC2/CID dataare printed only on the card; they are not contained in the magneticstripe information per se, nor do they appear on sales receipts orstatements. The use of these codes attempts to make it more difficultfor a person who has stolen a credit card number, but not the actualcard, to enter into fraudulent transactions, provided the other party orparties to such transactions have also invested in the requisite changesto their systems and processes to support the use of these codes.

[0019] The prior art attempts, with mixed results, to solve the commonproblem of how to authenticate and verify a transaction, such aspurchase, funds transfer, account opening or closing or modification,etc., particularly when conducted remotely or electronically; how toauthenticate and verify the relevant party or parties, and how toprovide the earliest possible warning of fraud, with a high degree ofaccuracy and completeness and near-zero delay.

[0020] U.S. Pat. No. 6,182,894 to Hackett describes systems and methodsto use CVV2/CVC2/CID values, in lieu of PIN codes, to verify that aconsumer engaged in a point-of-sale (POS) transaction possesses thetransaction card at the time of purchase and/or is the true card owner.The CVV2/CVC2/CID information is provided to the POS system as anadditional authenticating datum, and if said datum matches what isstored in the relevant authorization system for the applicable cardaccount number, and authorizing parameters are satisfied, authorizationproceeds. If not, authorization is denied. Such systems and methods donot protect against card theft or hacking (should such CVV2/CVC2/CIDdata flow from the consumer to the merchant or card processorelectronically, or are stored on an intermediate system), because theyauthenticate only that certain data from the physical card match datastored in the authorization system, without authenticating the identityof the card holder/user, and without verifying the intentions of thetrue card owner or other co-authorizing party (if different). Further,they do not provide the advantage of notification of the true card owneror other co-authorizing or auditing parties of the occurrence of atransaction, and in particular a high-risk transaction. Finally, suchsystems and methods also fail to provide for any additional automateddata gathering, authentication, and verification for and by the partyregarding the opening, closing, or modification of an account remotely.

[0021] U.S. Pat. No. 5,727,163 to Bezos describes a system and methodfor concluding a transaction by telephone that was initiated over theInternet. The purchaser dials a special telephone number associated withthe transaction and provides his/her credit card number in full bydialing it on his/her touch-tone keypad (that is, using DTMF tones).Such a system and method have the advantage of partially isolatingprivate payment information across two different communication links,but do not address the problem of notification or authentication of thelegitimate account holders or other parties having a potential interestin the transaction, nor verification of the intent and approval of saidlegitimate account holders or other parties having approval authorityfor the transaction. Instead, they provide assurance solely to thepurchaser that his/her private financial information need not becommunicated in full through a network perceived to be insecure (thatis, through the Internet). Such a system and method, which requirepurchasers to take additional proactive steps to complete remotetransactions, have had limited adoption by consumers and merchants dueto the complexity they add to all affected transactions. This system andmethod are further limited to collecting payment data, such as a creditcard number, for processing by the merchant's point-of-sale or orderingsystem, under the purchasing party's control. They do not provide forany additional data gathering, authentication, and verification for andby the party attempting to collect payment or open, close, or modify anaccount remotely, nor for and by any third party whose approval isnormally required to conclude the transaction.

[0022] U.S. Pat. No. 6,324,526 to D'Agostino describes a system andmethod for providing a transaction code, supplied case by case by thepurchaser's financial institution, in lieu of a credit card number for apurchase transaction. As has been noted, systems and methods based ondummy transaction or account number codes have had limited consumeracceptance because of the complexity to set up and use them. Suchsystems and methods attempt to address only the security of thepurchaser's account information, by eliminating exposure thereof to athird party over a network perceived to be insecure (that is, over theInternet). Nor do such systems and methods provide for any additionaldata gathering, authentication, and verification for and by the partyattempting to collect payment or open, close, or modify an accountremotely; nor for and by any third party whose approval is normallyrequired to conclude the transaction.

[0023] U.S. Pat. No. 6,270,011 to Gottfried describes a system andmethod for coupling a fingerprint recognition device to a credit cardscanner. As has been noted, systems and methods of this type haveextremely narrow application because of the need for the affectedparties' physical presence, the associated cost of implementation andon-going support, and general public concerns over personal privacy whenbiometric devices are employed. Systems and methods of this type attemptto address only authentication of a purchaser's identity, and ignorenotification of a party or parties who may be subject to identity fraudor fraudulent transactions.

[0024] U.S. Pat. No. 6,341,724 to Campisano describes a system andmethod for using the telephone number of a credit card owner, plus a PINcode, as an alias for the actual card number in a credit cardtransaction. This system and method replace the account number withanother sequence of digits which is not printed or encoded on the creditcard itself. Systems and methods of this type are a variation on theconcept of a dummy account number, per U.S. Pat. No. 6,324,526 toD'Agostino, and provide the benefit of allowing a purchaser to make acredit card purchase without having to remember his/her card number.However, such systems and methods do not provide protection against theuse of stolen account information, nor against the use of stolen dummyaccount information such as said telephone number and PIN. They furtherrequire credit card users to learn a new process for making credit cardpurchases, and require system and rule changes by merchants to allow thepurchaser's telephone number and PIN to be used in lieu of a cardaccount number. For debit card transactions, the purchasers wouldfurther have to supply two PIN values, one for the debit card account,the other for encryption purposes. Nor do such systems and methodsprovide for any additional data gathering, authentication, andverification for and by the party attempting to collect payment or open,close, or modify an account remotely; nor for and by any third partywhose approval is normally required to conclude the transaction.

[0025] U.S. Pat. No. 6,023,682 to Checchio describes a system and methodfor communicating a credit card number to a payment-authorizing computersystem from a point-of-sale credit card terminal, using encryption wherethe key is a personal identification code (“PIC”) belonging to the cardowner, and then verifying that the personal identification code matchesthat stored in the payment-authorizing computer system's memory. Thissystem and method introduce the advantage of using personal information(such as a PIN code) to verify a card-user's identity, but also requirechanges to payment authorization systems and merchant's order-taking orpayment-processing systems to implement, further require the purchaserto supply his/her personal identification code to the merchant, and haveutility only at a physical point-of-sale, that is, in a non-remotetransaction. Because the PIC is communicated through the same processand media as the transaction itself, said personal identification code,particularly for e-commerce transactions, is vulnerable to theft viahacking of the merchant's systems or interception of the merchant'scommunications to the payment-processing bank or applicable credit cardprocessing network. Such systems and methods also fail to provide forany additional data gathering, authentication, and verification for andby any third party whose approval is normally required to conclude thetransaction.

[0026] U.S. Pat. No. 6,088,683 to Jalili describes a method forcustomers to order goods from merchants on one network, such as theInternet, and then complete the purchase via a second network, such asthe telephone network, using “Caller ID” service or a call-back to checkthe customer's telephone number as a form of proof of the customer'sidentity, and involving an independent processing center that receivesthe customer's financial information over the second network in advanceand stores it for future reference. The merchant uses the second networkto deliver transaction details and the customer's ID to the processingcenter, which then uses the second network to receive or initiatecontact from/to to the customer to check his/her identity and his/herpurchase intentions. Said method revises the method described in U.S.Pat. No. 5,727,163 to Bezos, by moving responsibility for the exchangeof the customer's financial information from between the customer andmerchant over a second network at the time of the transaction, as perBezos, to between the customer and processing center over a secondnetwork in advance of the transaction. In Jalili, the processing centeralso performs the step of debiting and crediting the accounts of thecustomer and merchant, respectively. Therefore, the utility of thismethod is limited to cases wherein both a purchaser and a merchant areindependently willing and able to establish an advance relationshipwith, exchange private information (such as account information for thepurchaser and merchant processing information for the merchant) with,and allow debiting/crediting of their accounts by, such a processingcenter prior to entering into a purchase transaction between themselves.The method is also limited to purchases, and particularly to purchasesinvolving a single customer and a single merchant. The need for apreparatory process occurring over the second network, the need to usethe second network to perform all steps to prepare and conclude atransaction other than the step of the customer's placing of his/herorder, and the need to establish a processing center, also limit theutility of this method. Because the purchaser does not actually supplyhis/her payment information to the merchant, the method further createsan opportunity for fraud perpetrated within processing center, stemmingfrom its unique position of trust between the two other parties. If,however, the processing center is not independent of the merchant, thenany utility derived from the separation of the processing center fromthe merchant, such as the assurance to the customer that his/her privateaccount information need never be transmitted directly to the merchant,is lost. The method also adds the complication of the merchant having toprovide a new and additional or alternative form of customeridentification information to the processing center in order to receivea customer's payment. The method also fails to provide for anyadditional automated data gathering, authentication, and verificationfor and by a party regarding non-purchase transactions, such as theopening, closing, or modification of an account remotely; nor for and byany third party whose approval is normally required to conclude apurchase transaction. The method also fails to address purchases ornon-purchase transactions initiated other than via a network. Lastly,the method requires a new sort of account to be established, namely, thecustomer's registration with the processing center.

[0027] Additional weaknesses and limitations of the prior art in generalinclude:

[0028] Systems and methods of physical recognition: Such systems andmethods require deployment, training, and support of a new purchaserand/or merchant transaction-processing infrastructure on a wide scale(such as deployment of biometric scanners and related interfaces topayment systems) and require the physical presence of purchaser tointeract with that infrastructure to complete a transaction. Thissolution is therefore highly limited in the scope of its application.

[0029] Systems and methods using passwords and ID codes: Generallyeffective for ATM and debit card transactions, such systems and methodsare not used widely for credit card transactions. Passwords and codes(such as PIN codes) remain subject to theft (as by Internet hacking,card “skimming”, identity theft, etc.). Once a password or ID code iscompromised, no further safeguards are possible, and entirely newcustomer accounts must be created. Passwords and ID codes are notcommonly used, supported and enforced by merchants for credit cardpurchases.

[0030] Systems and methods using CVV2/CVC2/CID codes: Systems andmethods utilizing such codes are presently limited to credit cardaccounts only, do not protect against the loss or theft, such as byhacking, of credit or debit-and-credit cards or card account numbersalong with such codes, and do not prevent the fraudulent creation orsubsequent modification of an account.

[0031] Systems and methods using verification of private knowledge: Suchsystems and methods are vulnerable to theft of private information viahacking, and identity theft. This is particularly troublesomeinternationally, where the most common type of private knowledgechecking in the U.S. for credit card transactions, namely, an account'sbilling addresses, is rarely possible today abroad.

[0032] Systems and methods using smart cards: While smart cards addpassword (PIN) features and can also create dummy credit card numbersusable for one transaction only, systems and methods utilizing smartcards require the installation and use of a smart card reader by theuser, and have thus had limited adoption by consumers. These specialfeatures are further available only when purchases are made via thecomputing device where the smart card reader is installed.

[0033] Systems and methods using digital signature information(“E-Wallets”): As with smart cards, systems and methods for e-walletsrequire specialized software to be installed on the computing device ofthe e-wallet's owner, and therefore have not been widely adopted byconsumers. Their features are likewise only available for purchases madevia the computing device where such software is installed.

[0034] Other limitations and weaknesses in the prior art: Notificationof a transaction, and any interaction with the actual party or partieswho are truly authorized to conclude and approve it, as opposed tointeraction with parties who are perpetrating fraud by representingthemselves as said actual, authorized parties, is generally leftunaddressed by the prior art. Notification or interaction which doesoccur in the prior art is typically after the fact, either by theactual, authorized party's reviewing his/her billing or accountstatements, by consulting his/her credit report via a credit reportingagency, or, if the payment processor (for example, the relevant creditcard processor or bank) so determines, through a follow-up telephonecall from a customer service representative of such credit cardprocessor or bank, or through other messages delivered after the factthrough a variety of basic communications media. These inherentlyafter-the-fact processes do not interrupt or halt a fraudulent remotetransaction before it is completed, nor can they halt additionalfraudulent transactions (which may fit within a purchaser's normal riskprofile) made quickly thereafter using the same account number or otheridentifying information. Prior art which attempts to address theobjective of verification of a transaction before it is concluded addsprohibitive requirements for the establishment, registration with, anduse of intermediaries such as processing centers between customers andmerchants, fails to address the objectives of notification and approvalof or by thirdparties, and fails to address the class of transactionscomprising the opening, closing, and modification of accounts.

[0035] It is desirable to verify and authenticate a transaction, and inparticular a potentially risky transaction, without relying on theinstallation and use of new equipment by one or more of the partieshaving an interest in, involved in, or represented to be involved in,said transaction, nor requiring substantial alterations to existingprocesses or additional education and training for conducting suchtransactions, nor requiring new intermediary entities to be established.It is further desirable to do so in a manner that thwarts any potentialparty to such a transaction who attempts to authorize or enter into itfraudulently. It is further desirable for such verification andauthentication to work even when the mechanisms, systems and methodsdescribed in the prior art may already be in use but still fail toprotect fully against fraud, especially when fraud is perpetrated as aresult of the theft of private information. This is especially importantin the area of transactions conducted remotely, and in particularelectronically. It is also desirable to notify automatically the actualparty or parties having legitimate authority to approve or audit atransaction, whether directly engaged in such transaction or not, of theoccurrence and/or details of said transaction. It is also desirable tobe determine the behavior of any embodiment of a system and method forsuch notification, verification and authentication, through the use ofstored profiles of parties and transaction types and other parameters,and also through profile information and other parameters which may beprovided with and as part of an individual transaction.

[0036] The invention described herein provides a method and system forverifying, authenticating, and providing notification of a transaction,such as a commercial or financial transaction, with and/or to at leastone party represented or identified as engaging in said transaction orhaving a potential interest in said transaction or type of transaction,in particular a remote or electronic transaction, while it occurs and/orafter it occurs, via one or more of a plurality of communication linksand communication addresses associated with said at least one party, soas to create a higher degree of certainty that the transaction isnon-fraudulent than is possible using any of the prior art, withoutintroducing significant delay in the completion of legitimatetransactions, and without requiring implementation of new equipment orsoftware, or learning of unfamiliar processes or technologies, orestablishment and use of separate processing centers or otherintermediaries.

BRIEF SUMMARY OF THE INVENTION

[0037] It is an object of the invention to provide a means of verifyingand authenticating the identities and intentions of one, some or allparties represented or identified as engaging in a transaction or havinga potential interest in said transaction or type of transaction while itis in progress, and/or soon thereafter;

[0038] It is also an object of the invention to provide a means ofaccepting or obtaining information and parameters about saidtransaction, including information about one or more parties representedor identified as engaging in or having a potential interest in saidtransaction, from a transaction-processing system or device, such as abanking transaction system or credit card authorization or riskassessment system, as it is processing the transaction;

[0039] It is also an object of the invention to provide a means ofcommunications with and/or to one or more parties having a potentialinterest in the transaction, some of whom may be represented as engagedin the transaction through the use of identity-related data, such as anaccount number or numbers;

[0040] It is also an object of the invention to provide a means ofdefining, at the time of the transaction or in advance of thetransaction, or both, which specific parties have a potential interestin a given transaction, and the nature of such interest;

[0041] It is also an object of the invention to allow saidcommunications to occur over a plurality of communications media and/orcommunications links, to increase the likelihood of successful andsecure communication with and/or to said one or more parties,

[0042] It is also an object of the invention to provide a means ofdefining, initiating and controlling said interactions and theircontent;

[0043] It is also an object of the invention to provide a means ofobtaining and/or storing information about the nature, communicationaddresses, and other parameters of said one or more parties'communications devices used for said communications, to enableadditional verification and authentication of the identity or identitiesof said one or more parties;

[0044] It is also an object of the invention, in its preferredembodiment, to allow the behavior of said preferred embodiment to becontrolled and managed under varying conditions and circumstances inaccordance with stored profiles and, additionally or alternatively, inaccordance with information provided along with the transactioninformation;

[0045] It is also an object of the invention to provide a means, in itspreferred embodiment, for the adapting the inventive systems' behaviorbased on prevailing conditions and circumstances regarding saidtransaction, which conditions and circumstances may change during orbecause of the utilization of the invention;

[0046] It is also an object of the invention to provide a means ofrecording and remembering the details of said transaction and the resultor results of any subsequent communications for later review and use bythe user of the invention;

[0047] It is also an object of the invention to provide a means ofreporting and/or transmitting and/or forwarding a result or resultsregarding said transaction and said result or results of said subsequentcommunications.

[0048] Accordingly, the invention, to address the above and otherobjects, provides a system and method for verifying, authenticating, andproviding notification of a transaction, such as a commercial orfinancial transaction, with and/or to at least one party represented oridentified as engaging in said transaction or having a potentialinterest in said transaction or type of transaction, in particular aremote or electronic transaction, while it occurs and/or after itoccurs, and in accordance with any parameters which may be supplied inor with information about the transaction, additionally or alternativelywith any profile or profiles which may be associated with thetransaction.

[0049] In the preferred embodiment of the invention, the occurrence ofcommunications with said at least one party and at least one of aplurality of communications devices and associated predeterminedcommunications addresses known to belong to said at least one party,using at least one communications link other than the communicationslink used to initiate the transaction itself, isolates the transactionmedium or environment from the notification and/or verification mediumor environment, such that a very high degree of accuracy andcompleteness of authentication and verification can be achieved with aminimum of delay, and without requiring any newauthentication/verification technologies to be implemented or learned bythe transacting party or parties.

[0050] The invention goes beyond current practices by providing a highlyautomated means and a method for, individually and in combination:

[0051] 1. Notification, verification and authentication of any or all ofthe party or parties involved in, identified as involved in, and/orpredetermined to have a potential interest in, a transaction while it isstill in progress, and/or afterward;

[0052] 2. Verifying and authenticating using a plurality ofcommunications links which may operate on networks havingnear-universal, worldwide availability and high reliability;

[0053] 3. Separating and isolating the communications link and/or mediumof the initial transaction (for example, the World Wide Web) from thecommunications link(s) and/or medium or media used to verify andauthenticate it (for example, the public switched telephone network,wireless networks, Instant Messaging services), in such cases as thetransaction's primary medium is deemed insufficiently secure orinsufficiently able to verify and authenticate a party or parties;

[0054] 4. Utilizing a plurality of concurrent and/or sequentialcommunications with and/or to a plurality of communications devices andaddresses, using a plurality of communications links and communicationsmedia;

[0055] 5. Attempting communications with and/or to any or all of theparty or parties involved in, identified as involved in, and/orpredetermined to have a potential interest in transaction usingalternate communications links or media in the event that attemptedinteraction or interactions using the preferred associatedcommunications link or medium fails;

[0056] 6. Predefining and dynamically determining a plurality ofsequences of actions and communications to be taken under differingconditions for differing transactions and differing pluralities ofparties thereto, based on information and parameters regarding thetransaction and/or user-definable profiles regarding transactions, typesof transactions, and/or parties and potential parties involved in,identified as involved in, and/or predetermined to have a potentialinterest in such transactions;

[0057] 7. Communicating with a third party or parties involved in,identified as involved in, and/or predetermined to have a potentialinterest in, who are not initially part of such a transaction (such asan employer, parent, or law enforcement official in performance ofhis/her duty), for purposes such as seeking such third party or parties'approval thereof, or to notify same;

[0058] 8. Assigning one or more roles to one or more parties involvedin, identified as involved in, and/or predetermined to have a potentialinterest in a transaction;

[0059] 9. Interacting differently with each of said one or more partiesbased upon his/her ascribed role;

[0060] 10. Avoiding intrusiveness in the consummation of thetransaction, by eliminating the need to install and proactively use anynew or unfamiliar equipment, software, processes, or purchasing methodsby the party or parties having an interest in, involved in, orrepresented to be involved in the transaction;

[0061] 11. Intermingling of parameter-based non-transactionalinformation, such as sales, marketing, product or support information,with transaction and confirmation information in said communications,and

[0062] 12. Predetermining and/or dynamically determining the format andcontent of said communications, such as via user-defined templatesand/or scripts.

[0063] The preferred embodiment of the invention associates one or morepredetermined communications devices and addresses, such as telephonenumbers or wireless SIP addresses, with a plurality of parties who mayhave an interest in, be involved in, or be identified as involved in, atransaction, and related identifying information, which may include anaccount number or credit card number. Such identity, device and addressinformation are preferably defined and stored in advance in anon-volatile storage or database in the form of a profile associatedwith each such party, or are additionally or alternatively provided tothe inventive system within or along with information about a specifictransaction.

[0064] When a transaction is initiated with reference to such party orparties, such as via identifiers such as credit card account number(s),bank account numbers, or Social Security Numbers (SSNs) or taxidentification numbers, a central system then attempts to communicatevia a plurality of communications links with and/or to one or more ofsaid plurality of parties via at least one of each such party's known,predetermined communications device(s), to notify the party or partiesof the transaction and, additionally or alternatively, to interact withthe party or parties to authenticate and verify their identities,intentions and/or approvals in regard to the transaction. The inventionfurther provides several alternative means and methods for establishingsuch communications with and/or to each such party, either in parallelor serially, in the event that the primary means and/or methodassociated with each such party is not successful. Each communication orset of communications is preferably governed by logic rules, which maybe predefined or dynamically determined, and which may be encoded as ascript to be executed in or by the central system, said rules beingdetermined in part based upon a categorization of the transaction, theidentities or a categorization of one or more of said plurality ofparties, and/or other parameters obtained along with the informationdescribing the transaction.

[0065] Because each such interaction occurs with the actual owner/userof the communication device at a known and predefined communicationsaddress (such as his/her pre-verified wireless SIP address), if anyparty engaged in the transaction is not the owner/user of saidpredefined communications address, then 1) the interaction by definitionalerts the actual owner/user to a fraudulent transaction in progress,and 2) the fraudulent owner/user is thwarted, because he/she will bephysically unable to authenticate him/herself using the communicationsdevice found at said communications address. Further, even if thefraudulent party is able to obtain such a communications devicebelonging to the true owning/using party, the fraudulent party muststill supply further authenticating information presumed to be knownonly to the actual owning/using party. Preferably, the communicationslinkage employed for such interaction is different from thecommunications linkage used to initiate the transaction, thereby furtherlimiting the potential for fraud and for the theft of privateinformation.

[0066] Additional utility may be derived when the user of the inventionis in the role of a financial services organization, such as a creditcard issuer, payments-processing network, merchant processor oracquirer, employing the invention alongside or within itstransaction-authorization and/or account-management processes andsystems to reduce transactional risk for its merchant and/or consumercustomers. Such financial services organizations already have, in thenormal course of their business, advance knowledge of potential partiesto transactions, including identifying information and other parametersabout such parties which may include their account numbers and theircontact information, such as home telephone numbers, e-mail addresses,and wireless device addresses; knowledge of transactions relating totheir customers as they occur; and a presumed relationship of trust withsaid potential parties to transactions. Their advance knowledge andexisting trust relationships minimize their effort to implement andwidely deploy the invention for maximum utility. In addition to thefraud-reducing and fraud “early warning” benefit of the invention,financial services organizations may also benefit from improved customerrelationships through increased value-adding contacts occurring as aresult of the use of the invention, and from the resulting higher levelof service provided. Financial service organizations that employ theinvention may also benefit from the utility of a reduced perception bytheir consumer and merchant customers of the risks of conductingtransactions electronically or remotely. Note that the additionalutility to entities in the role of financial services organizations isnot inherently limited to such entities, nor is it the only additionalutility they may obtain. This and other additional utility may be alsobe obtained by other users, whether utilizing a similar or alternativeembodiment of the invention.

[0067] In the preferred embodiment of the invention, when a transactionmessage is received by the central system from a second system ordevice, the central system parses the received message, authenticatessaid second system or device, and then may use the parsed data values todetermine or derive a set of corresponding rules that inform or definethe central system's subsequent actions and subsequent communicationswith or to a relevant party or parties over a plurality of communicationlinks. Such rules may be predefined, and if predefined are stored inadvance in the central system's volatile and/or nonvolatile storagememory or database(s). The central system takes a plurality of actionsaccording to said rules.

[0068] In the preferred embodiment, the central system may establish aplurality of communications links, which may include but are not limitedto wireless and landline telephony, SMS and wireless text messaging,instant messaging, and electronic mail and other Internet Protocol (IP)transmissions, in a sequence defined by said rules, to reach a pluralityof parties having a potential interest in, involved in, or representedto be involved in, said transaction. The central system attempts tocommunicate with and/or to each of said plurality of parties via atleast one predefined communications device specifically associated withthat party.

[0069] As each of said communication links is successfully established,the central system preferably delivers information to the correspondingparty regarding the transaction, which information may include 1) thetransaction details, which may include the nature or purpose of thetransaction and/or a total price or amount, 2) additional information ofpotential value to said party, such as product-, sales-, service- and/ormarketing-related information provided by the other party/parties or athird party or parties, and 3) other parameters, which may includeidentifying information regarding one or more of said parties. Saiddelivery of information is preferably composed and formatted by thecentral system per a predefined message template or script that may berelated to the transaction or the type of transaction, thecommunications medium employed, and the language in which the party isknown to be conversant. For example, in a telephone call, said deliveryof information may be comprised of concatenated segments of prerecordedaudio and/or text-to-speech synthesis.

[0070] Each such party may then be prompted to confirm his/her identityand intentions, which may include providing a PIN code, CVV2/CVC2/CIDcode (for a credit card), or other unique and private identifier(s),such as the initial letters of his/her mother's maiden name, which datumor data may be predefined to the central system, or may be suppliedwithin or derived from the initiating transaction message. A confirmingaction or actions may be performed by said party via said communicationslink, using a means appropriate to his/her corresponding communicationsdevice. For example, on a telephone, DTMF digits may be pressed toconvey the information prompted for by the central system.

[0071] Based on the results of said interaction(s) with said pluralityof parties, the central system preferably computes or otherwise derivesa result, which it then preferably transmits to said second system ordevice from which the transaction message originated, and/or to anassociated third system. Further, based on said retrieved stored rulesand/or said dynamically derived rules, the central system alsopreferably transmits one or more of a plurality of notification messagesabout said transaction and said result to one or more of said pluralityof parties, over a plurality of communication links, and may also logsaid results in a nonvolatile memory or other storage or database forlater retrieval, action, and/or analysis, and/or for billing purposes.

[0072] The central system communicates through a plurality ofcommunications links using a plurality of communications protocols,configured according to such rules as are to be supported andimplemented in any specific embodiment of the invention. Thesecommunication links and protocols may include but are not limited towireless and wireline telephony (which may include text-to-speechprocessing, recorded speech, DTMF tones, and combinations thereof),electronic mail, instant messaging (IM), fax, paging, Short MessageService (SMS) and other wireless text messaging, and other existingwidely used services and protocols, as described more fully hereafter.In the preferred embodiment of the invention, the central system alsoprovides a means to add and delete a plurality of types of communicationlinks and protocols, as such types of communication links and protocolsbecome available and desirable or cease to be available or desirable;and a means of receiving, translating, and acting upon a plurality ofinformational codes and formats of transaction message as may beprovided by differing types of second system or device originating suchtransaction message under differing conditions.

BRIEF DESCRIPTION OF THE DRAWINGS

[0073]FIG. 1. System Diagram—Preferred Embodiment

[0074]FIG. 2. Application Programming Interface Generalized Schema

[0075]FIG. 3. Networking Configuration

[0076]FIG. 4. Remote Transaction Engine Communications Interfaces—DataMessaging Layer

[0077]FIG. 5. Rules Database View

[0078]FIG. 6. Profiles Database Views

[0079]FIG. 7. Party-Transaction Group Profiles Database View

[0080]FIG. 8. Communications Sequence Patterns Database View

[0081]FIG. 9. Scripts Database View

[0082]FIG. 10. Message Templates Database View

[0083]FIG. 11. Communications Subsystems: Telephony

[0084]FIG. 12. Communications Subsystems: E-mail

[0085]FIG. 13. Communications Subsystems: Instant Messaging

[0086]FIG. 14. Communications Subsystems: Fax

[0087]FIG. 15. Communications Subsystems: Paging

[0088]FIG. 16. Communications Subsystems: Wireless Text Messaging/ShortMessage Service

[0089]FIG. 17. Communications Subsystems: Wireless Telephony

[0090]FIG. 18. Communications Subsystems: IP Telephony

[0091]FIG. 19. Communications Subsystems: Internet DataProtocols—HTTP/HTTPS using HTML/XML

[0092]FIG. 20. Communications Subsystems: WAP

[0093]FIG. 21. Communications Subsystems: Telex

[0094]FIG. 22. Communications Subsystems: FTP

[0095]FIG. 23. Communications Subsystems: SNA/RJE Datasets

[0096]FIG. 24. Communications Subsystems: EDI/EDIFACT/EDI-INT

[0097]FIG. 25. Generalized Process Diagram

[0098]FIG. 26. Communication Scripting Language Statements, ObjectMethods, Properties, and Environment Variables

[0099]FIG. 11-FIG. 24 are schematics of the links between a preferredembodiment of a system according to the invention and a range ofpotential communications devices used or usable by potential parties toa transaction.

DETAILED DESCRIPTION OF THE INVENTION

[0100] The invention achieves a very high degree of accuracy andcompleteness of authentication, notification and verification of atransaction and the identity and intentions of one or more of theplurality of parties represented as entering into or conducting thetransaction, with a minimum of delay, and without requiring newauthentication/verification technologies to be implemented or learned bysuch parties, by:

[0101] a) Automatically communicating with and/or to the relevant partyor parties represented as conducting a transaction, such as anelectronic or remote transaction, using at least one communications linkwhich is typically and preferably other than the one used to initiatethe transaction itself, if any;

[0102] b) Communicating with and/or to said party or parties only oncommunications devices having specific predetermined communicationsaddresses known to belong to them, as a mechanism of additionalauthentication and verification;

[0103] c) Additionally or alternatively, further verifying said party orparties' stated identities by cross-checking physical information knownor discernable about their communications devices (e.g., telephoneAutomatic Number Identifier value) with other, external sources ofidentity information (e.g., a telephone number billing addressdatabase);

[0104] d) Notifying said party or parties of the transaction's details,such as a merchant's identity, purchase amount, etc., through saidcommunications devices;

[0105] e) Additionally or alternatively, providing supplementalinformation of potential utility to said party or parties, such assales, marketing, product and support-related information, through saidcommunications devices;

[0106] f) Additionally or alternatively, interrogating said party orparties to further authenticate their identities and/or verify theirintentions regarding the transaction using said at least onecommunications link;

[0107] g) Additionally or alternatively, further verifying said party orparties' stated identities and intentions by obtaining confirming inputfrom said party or parties, through said communications devices, whichmay include passwords or other private knowledge (such as a predefinedPIN code, predefined CVC2/CVV2/CID code, or several initial letters of apredefined security word such as a mother's maiden name) through saidcommunications devices;

[0108] h) Enabling communication with and/or to one or more of aplurality of parties related directly or indirectly to the transaction,some of whom may not have been identified or were not known to eitherthe initiating parties or to the system or entity (remote to theinventive system) responsible for processing the transaction, and

[0109] i) Supporting stored, user-definable profiles, rules, andparameters regarding such transactions and such parties, which profiles,rules, and parameters, in a preferred embodiment, are used to vary thebehavior of the inventive system and thereby the sequence of stepsfollowed in the inventive method.

[0110] outside the transaction environment itself. The above advantagesapply whether the transaction is still in progress, or after the fact.

[0111]FIG. 1 presents a potential embodiment of a system consistent withthe invention. FIG. 25 shows a generalized process flow forauthenticating and verifying a typical transaction using said embodimentof a system, consistent with the invention.

[0112] In FIG. 1, a Remote Transaction Engine [1], such as a webe-commerce server or a credit card authorization system or device,processes a transaction initiated by one or more parties. The RTE [1]may, for example, be operated by a merchant conducting remotetransactions (as by Internet or by telephone) with its customers; by twoor more parties seeking to exchange goods, services, or funds; by afinancial institution conducting a financial transaction with a customer(as via Automated Teller Machine); by a payment processor organizationin behalf of a merchant; by a payments clearing network in behalf of apayment processor organization; by a payment-account issuer in behalf ofthe payments clearing network and the customer; by a financialinstitution or merchant establishing or modifying an account such as acredit account for a customer or prospective customer, or by a servicebureau in behalf of any of these. The sole requirement of the RTE [1] isto be able to provide a data message via an application programminginterface [11] (“API”) means, predefined specification means, or otherequivalent means to the Central System [2] (“CS”) of the embodiment ofthe invention, via any one of several standard communications protocolsover a communication link or network [31]. This transaction-describingmessage shall hereafter be called the Transaction Message.

[0113]FIG. 4 presents a plurality of communication links which may beutilized in an embodiment of the inventive system for receipt of saidTransaction Message from the RTE [1]. A plurality of preferred datacommunication link types [411-420] is shown, plus a voice-basedcommunication link based on DTMF signaling [421]. The inventive systempreferably further accommodates adding other and future protocols [425]as interfaces for them become desirable and available, and removingexisting protocols as they cease to be desirable or available. Differentembodiments of the invention may support varying sets of suchcommunication links from system to system, or on the same system overtime.

[0114] The Transaction Message is received by the CS's [2] DataMessaging Layer [FIG. 1, 201]. The Data Messaging Layer [201] iscomprised of various hardware and software modules and interfaces forreceipt, queuing and interpretation of messages from a plurality ofnetworks [FIG. 4], and may be implemented, for example, usingtechnologies such as message queuing middleware for data communications,and an Interactive Voice Response (IVR) unit for DMTF-based telephonymessages.

[0115] The Transaction Message, if communicated over a public datanetwork or other potentially insecure network, such as the Internet, maybe further encoded or encrypted either in whole or in part by the RTE[1] for added security, such as with PKI encryption or a similarstandard encrypting protocol, such as the Internet's TLS.

[0116] The preferred CS [2] in general is further comprised of one ormore processors; memories and data storage; software and softwarelibraries, such as may be written in and accompany the C++ and Javaprogramming languages, for handling and manipulating said message asdescribed hereafter; an operating system for managing low-level elementsof the system; security elements, such as firewall and/or encryptionsoftware, for limiting external access to the system, encryptingcontent, and defending against various forms of electronic attack uponit; and, database or other data-managing software, to store, manage, andperform searches and retrievals on information about parties,transactions, transaction processing rules, communication methods, andthe like, as more fully described hereafter. The CS [2] is additionallycomprised of a range of communications hardware and software,collectively referred to as the “Communications Subsystems,” which areused to notify or interact with one or more of a plurality of partiesrepresented or identified as engaging in a transaction or having apotential interest in a transaction. Said Communications Subsystems[211-218, ff.] are described further hereafter.

[0117] The minimum necessary contents of said Transaction Message areshown in FIG. 2. The choice of minimum necessary contents may vary fromembodiment to embodiment of the inventive system. These data fields andvalues 1) identify the transaction-originating entity [21 a], 2) providea mechanism to authenticate it [21 b], 3) identify one or more partieshaving a potential interest in, involved in, and/or represented to beinvolved in, the transaction [22 a, ff., 22 b, ff.], 4) identify thetype of transaction [22 c], such as a credit card purchase withcard-not-present, and 5) identify the price or amount of the transaction[22 d] if applicable. Preferably, the types of transactions known to thesystem are all user-definable in advance through the User Web Client[FIG. 1, 251] (see below) or via a bulk or automated load to the CS's[2] databases.

[0118] Additional data fields and values may be supplied in theTransaction Message to further define the party or parties'communication addresses to be used in authenticating this transaction[23 c,f, ff., 23 d, ff.]; a specific stored Rule Set (see below) to beinvoked [23 i]; a specific stored message content template to be usedeither for this transaction in general [23 j,k] or for each party [231,ff.]; additional information to transmit to the relevant party orparties during the communications sessions which follow [23 o,p], andthe like, as enumerated more fully in FIG. 2. There is also specificprovision for a mechanism to include user-defined fields and data valueswithin said Transaction Message [23 p]. These additional data in theTransaction Message, if present, preferably supersede such values as maybe stored in advance in the CS's [2] databases about a given type oftransaction, parties, Rule Sets, and so on.

[0119] The message protocol and format of the Transaction Message isdefined according to the physical or logical port and/or communicationservice through which it arrives at the CS's [2] Data Messaging Layer[201], and additionally (for certain types of Internet messages)according to meta-tags and/or content-descriptor codes found at thestart of the message which further define the formatting and content ofthe message. The message is parsed by the Data Messaging Layer [201]according to said format and protocol, and thereby decomposed into aseries of name-value pairs which correspond to the data fields shown inFIG. 2. The incoming data are thus normalized into a standard internalformat for subsequent processing, independent of their originatingformat.

[0120] If the minimum required information as identified in FIG. 2 isnot present, or if the RTE [1, 21 a-b] cannot be authenticated, the CS's[2] Data Messaging Layer [201] rejects the Transaction Message and sendsa corresponding rejection message back to the RTE [1]; in a typicalembodiment, the rejection message is composed and transmitted via thesame protocol used for receipt of the incoming message [FIG. 4,421-431].

[0121] Where any name-value pair is not defined in the message, defaultvalues are looked up in the CS's [2] primary database tables and views[FIG. 5-FIG. 8] using the RTE ID [21 a], transaction type [22 a] andparty identifiers(s) [22 a, ff.] as the index values, via, for example,an SQL query or a stored (database) procedure. Note that the CS enforcesthat any variable-length lists of required name-value pairs, such as thelist of parties, require at least one name-value pair be explicitlydefined in the incoming Transaction Message for said message to bedeemed valid.

[0122] If any of the parties is a member of a Party Group, either byprior association therewith through the CS's [2] Parties database view,shown in FIG. 6 [6 d], or as superseded by data in the TransactionMessage, per FIG. 2 [23 f], the Data Messaging Layer [201] adds theidentities [FIG. 7, 7c] and roles [7 e] of the parties belonging to thecorresponding Group to the list of parties to be contacted for thetransaction. In this way, certain transaction types for a given partymay automatically spawn communications with additional parties, such asan employee's work supervisors or auditors, a minor's parents, or lawenforcement personnel, without requiring explicit mention of suchadditional parties in the incoming Transaction Message. Such Groups arepreferably user-definable in advance, via the mechanism of the Profiledatabases [FIG. 6] and the User Web Client [FIG. 1, 251]. This featureof the invention creates significant advantages over the prior art, byallowing automatic inclusion of a variety of additional parties inapproval, notification and auditing roles.

[0123] Each party is given a Role in accordance with its Profile [FIG.6, 6k], if any; its inclusion via the Party Group mechanism [FIG. 7,7e]; or, as superseded by data in the Transaction Message, per FIG. 2[23]. Another important advantage of the invention is the automaticassignment of Roles to the party or parties of the transaction, suchthat different actions may be taken in regard to each party based uponnot only the party's identity but also the Role of the party in thetransaction. One embodiment of the invention uses roles such as“Confirm” for a party that is to provide input to the inventive system,once contact has been established therewith, for example to furtherauthenticate his/her identity and re-approve the transaction; “Notify”for a party that is only to be made aware of the transaction by theinventive system, and “Present” for a party with whom contact is not tobe established, but whose related data and parameters are to beconsulted and validated by the inventive system as part of thecomputation and delivery of a result message to the RTE [1].

[0124] Once the incoming Transaction Message's contents are validated,the full list of target parties and their roles is defined, and allrelevant name-value pairs that enable subsequent processing areestablished, then a software-based object or other data structure (the“Transaction Object”) containing these data is created in the CS's [2]volatile and/or nonvolatile memory or storage. The Transaction Object isthen queued for subsequent processing by the Rules and Script ProcessingLayer [202] (“RSP”) of the CS [2].

[0125] The RSP [202], in addition to sharing the basic elements of theCS [2] as described above, is comprised of programming and databaselogic for the execution of both stored and dynamically-defined ActionScripts, where such Action Scripts define generalized, parameterizedprocesses for communicating with and/or to one or more parties. Thebasic functions and components of such Scripts are shown and describedin detail in FIG. 26. The concept of fully user-programmable, adaptive,dynamic logic to control both the processing of individual transactionsand the execution of the related communications with one or more of itsparties is an important innovation introduced in and enhancing the valueof the invention, by allowing the inventive system to perform a varietyof distinct actions and sequences of actions based on each transaction'stype, parties and roles, and prevailing conditions and parameters, andon the real-time progress of the transaction through the inventivesystem.

[0126] The RSP [202] draws on the queue of work created in the CS's [2]memory or other storage by the Data Messaging Layer [201], each workitem being one Transaction Object comprised of 1) name-value pairsdescribing the transaction, as manipulated by the Data Messaging Layer[201] and available to scripts as Environment Variables (see FIG. 26),2) an associated Script, designated as described below, and 3) anevolving set of pending and actual communications link sessions and theresults thereof, further described below.

[0127] Transaction Objects may be drawn from this queue in sequentialorder, unless there is an overlap among the identified parties of two ormore such Transaction Objects. In such a case, the following logic ispreferably applied: 1) If the parties' roles are all, for example,“Notify” [per FIG. 6], the Transaction Objects may be merged, such thatmultiple notifications of multiple transactions may be sent to the sameparties using the same communications sessions. 2) If any of theparties' roles are, for example, “Confirm”, then the second TransactionObject is not drawn from the queue by the RSP [202] until the RSP [202]has completely finished working on any prior overlapping TransactionObject(s). This gatekeeping logic creates a unique advantage byprohibiting conflicting (and potentially confusing, or inherentlyfailure-prone) communications link attempts to the same party or partiesat the same time.

[0128] The Script associated with a given Transaction Object maypreferably be determined as follows. First, the Rule Set [FIG. 2, 23i]for the transaction, if identified in the incoming Transaction Message,is found in the Rules database view [FIG. 5] using, for example, an SQLquery or stored (database) procedure. If it was not so identified, acorresponding default Rule Set matching the transaction type and partyis found in the CS's [2] Profiles database view [FIG. 6, 6e] using, forexample, an SQL query or stored (database) procedure. If thecorresponding Rule Set returned by the query is null, a System DefaultRule Set may be used in its place.

[0129] Once the Rule Set is known and associated with the TransactionObject, its record in the Rule Set database view may be used to providethe following information, which may be used to control the furtherprocessing the transaction, per FIG. 5:

[0130] Message Template ID [5 b], along with the Transaction Language [5d], defines what message template (per FIG. 10) will be used to generatethe contents of the actual communications with the party (or parties)for this transaction. This value becomes an Environment Variable (seeFIG. 26) for the transaction.

[0131] Message Template Stylesheet URL [5 c] alternatively oradditionally allows a web-based stylesheet, such as an XML-based (i.e.,XSL) document, to be retrieved and used to format the aforesaid messageto the party (or parties), via reference to a Universal Resource Locator(URL). This provides the advantage of allowing the operator or user ofthe RTE [1] to dynamically redefine the presentation of information tothe relevant parties merely by updating an accessible web site with anew presentation format applicable to one or more of the transactionssaid RTL [1] may originate.

[0132] As such, this aspect of the inventive system is an importantinnovation, by providing its users with a programmable message contentand formatting mechanism that need not be maintained in or supplied tothe inventive system, but may instead be incorporated dynamically, byreference, at the time the transaction is processed.

[0133] Transaction Language [5 d] is used along with the MessageTemplate ID [5 b] to define the message template.

[0134] Transaction Currency [5 e] is used when financial amounts arereferenced in the communication to or with the party or parties.

[0135] Confirming Value Type [5 f] defines what form and format of datumis required as input from the party to successfully authenticate andverify the transaction and the party's identity. It may be a value suchas “PIN” for a PIN code, or “CVV2,” “CVC2,” or “CID” for a credit cardconfirmation code, for example.

[0136] External Media Address Reference Flag [5 g], if True, indicatesthat an external database call shall be made to a service provider [FIG.1, 12, “Remote Data Sources”] or other external data source which canprovide additional information about the party's communication addressor identity, such as the billing telephone address for the party's hometelephone number, for cross-referencing and/or logging purposes and/orfor later use in computing the result for the party.

[0137] Allowed Media [5 h] encodes, such as in a text string or binaryvalue, the types of communications links and/or media applicable to thistype of transaction for this party. This media list acts as a filter onthe party's communication profile records [FIG. 6], limiting thecommunication link alternatives for the party to only those link and/ormedia which are coded for in the Allowed Media [5 h] field. For example,the party may have e-mail as one communication preference, but for acertain transaction type, the Allowed Media [5 h] filter value keepse-mail from being used to authenticate and verify the party and his/herintentions for the transaction, for example to avoid the time-delay andrelatively low level of security associated with e-mail-basedcommunications, while for other transaction types, e-mail is still used,in accordance with the Profile. The RSP [202] insures that in no caseare fewer than one communication link alternative in force under anycircumstances, even if the use of that one alternative would otherwiseviolate the Allowed Media [5 h] filter.

[0138] Script ID [5 i] defines which Action Script [FIG. 9 and FIG. 26]is to be employed for the transaction. (The Script defines how the CS[2] will interact with the party or parties hereafter.)

[0139] Default Communications Sequence Pattern ID [5 j] identifies thedefault communication strategy to be used when attempting to reach theparty or parties. This value may be overridden by any CommunicationSequence Pattern [FIG. 6, 6n] defined in the CS's [2] databases, or inthe Transaction Message, for any specific party or parties for thistransaction type.

[0140] Once the above data have been gathered and stored in the system'smemory or other storage along with the other transaction informationaggregated into the Transaction Object, the RSP [202] executes theaforesaid Script. In general, Scripts preferably 1) attempt to establishcommunication link sessions simultaneously with all relevant partiesassociated with the transaction, and where possible, 2) deliver messagesto the parties over such communication link sessions, 3) prompt for andaccept input from the party of parties defined as having, for example,“Confirm” Roles [FIG. 6, 6k; FIG. 7, 7e], 4) compute an overall resultsummarizing the outcomes of all such communications and communicationattempts, 5) optionally log the transaction, communication attemptresults, and said outcomes and overall result, and 6) communicate theresult back to the RTE [1].

[0141] An important advantage of the invention is the adaptive logicrepresented by such Scripts, in lieu of a static process logic mechanismthat executes a single statically-defined sequence of instructions inevery case and under every condition.

[0142] In general, for each party, the preferred embodiment's RSP [202]will perform the following standard actions under the control of theScript [5 i]. Note that communications to multiple parties will occursimultaneously (unless directed otherwise by said Script) viaconcurrently executing, asynchronous system processes in the CS's [2]Communications Control Layer [203] (“CCL”). The process flow for thepreferred embodiment of the invention, with the RSP [202] executing aScript, is diagrammed in FIG. 25, in which the RSP [202] will perform inaccordance with a method comprising the steps of:

[0143] 1. Perform an external database or data service query orreference [B], as of, for example, a telephone number billing addressdatabase, using relevant data about the party as a key (for example,his/her telephone number), to gather external data about the party foruse in computing the result for the party and the overall result messageto the RTE [1], provided the External Media Address Reference Flag [FIG.5, 5g] (see above) for the transaction's Rule Set is True [A].

[0144] 2. Consult the party's Communication Profile record [FIG. 6,6a-c, 6 i-o] for this transaction type and account number (ifapplicable), using an SQL query or stored (database) procedure, andthen:

[0145] a. Group all the corresponding communication devices, addresses,and media for the party by their Communications Sequence Group [61](“CSG”) number, if applicable;

[0146] b. Where no CSG number is assigned to a communication device, adistinct temporary CSG is assigned by the RSP [202] to each such device;

[0147] c. Order the CSGs by the associated Communications Priority [6 m]number; this step defines the order in which the party's communicationdevices will be tried, with the Group mechanism of step (a) collectingmultiple devices to be tried together simultaneously;

[0148] d. Identify i) the party's Role [6 k] for this device, address,and media type (noting that not all supported devices and media typesnecessarily support two-way interactive communications), ii) theexpected Confirmation Value [6 O], if any, for “Confirm”-type parties(noting that this value may have been additionally or alternativelysupplied in the incoming Transaction Message from the RTE [1]), and iii)the Communications Sequence Pattern ID [6 n].

[0149] The above steps (a)-(d) are aggregated in FIG. 25 as process box[C], “Select Party's next device Group (CSG)”.

[0150] 3. For each Communications Sequence Group [61] for the party, inascending order of Communications Priority [6 m], initiate simultaneous,multithreaded communications sessions to all devices within said CSG[61] via the Communications Control Layer [203] (“CCL”) [FIG. 25, D].The CCL [203] initiates such sessions via commands it issues to theCommunications Subsystems [FIG. 1, 212-218 ff.]

[0151] A Communications Sequence Group [61] with more than onecommunications device and address in it causes the CCL [203] to attemptto reach a single party simultaneously on a plurality of his/her devicesand addresses. The first such contact attempt to succeed [E] becomes thesole active communication session to the party, and all other sessionsare immediately, automatically terminated [F]. This is accomplishedthrough the CCL's [203] monitoring and analyzing session-progress events[per FIG. 8, 8k: “Generate Event on Connection Flag”] generated via thevarious Communications Subsystems [FIG. 1, 211-218 ff.]. In practice,most Communications Sequence Groups [61] will contain just one deviceand addresses, and thus just one communication session at a time will beattempted for each party.

[0152] Once a communication session is successfully initiated with aparty on a given device and at a given communication address (such as atelephone with a particular telephone number) in a “Confirm” Role [FIG.6, 6k; FIG. 7, 7e], as per FIG. 25 [1], no further attempts to interactwith that party in its “Confirm” Role for the current transaction arepreferably made. However, further communications may preferably continueto occur in a “Notify” role. This may be accomplished by the CCL [203]setting a flag or semaphore [FIG. 25, 1] for the party (such as thePartyConfirmed[n] Environment Variable per FIG. 26) once one “Confirm”contact has occurred, such that further “Confirm” devices are ignored bythe CCL [203] for the current party in the current transaction [FIG. 25,M].

[0153] This feature contributes a special advantage of the invention, byallowing a given party to engage in contact with the inventive system inmultiple Roles for the same transaction, such as, for example, a“Confirm” Role on his/her mobile Instant Messaging device and a “Notify”Role to his/her e-mail system.

[0154] 4. Each communications device for the party has an associateduser-defined Communications Sequence Pattern [FIG. 8, 8a] that is usedto manage the attempts to reach and establish a communication linksession with the device; for each such Pattern, consult itsCommunication Sequence Pattern [8 a] database record, via SQL query orstored (database) procedure, to obtain the following parameters, or theequivalent, in a preferred embodiment of the inventive system:

[0155] Interactivity Flag [8 b], which specifies whether input from theparty is possible from said device;

[0156] Outbound/Inbound [8 c], which specifies whether the communicationlink is to be initiated by the CCL [203] or by the party communicatinginbound to the CCL [203];

[0157] Attempt Timeout Value [8 d], which sets the time before anattempt is deemed to have failed (for example, for a phonecall withmultiple rings and no answer);

[0158] Sequence Timeout Value [8 e], which sets the total time before anentire Sequence is deemed to have failed if no successful connectionoccurs;

[0159] First Attempt Delay [8 f], which postpones the first attempt atcommunication link session by a fixed amount of time (for example, toallow a party to switch his/her line from data to voice mode on adual-purpose communication device);

[0160] Smart Retry Flag [8 g], which, if True, instructs the CCL [203]to time subsequent communication attempts based on the outcome of theprior attempt (for example, retrying a phone number sooner if the lastresult was busy, vs. ring-without-answer);

[0161] Maximum Number of Attempts [8 h], which defines a total number ofattempts allowed before conceding failure;

[0162] Attempts Spacing [8 i], which defines the timing betweensubsequent attempts, and alternatively or additionally, between specificattempts in the Sequence;

[0163] Action on Final Failure [8 j], which defines whether upon theultimate failure of the sequence, a new sequence should begin (e.g., aSequence Pattern in which the system waits for the party to call it), ornot, and

[0164] Generate Event on Connection Flag [8 k], which, if True,instructs the communication process executing the connection attempt tosend an alert event to the CCL [203] upon success. This event is used inconjunction with Communication Sequence Groups [61] to identify which ofa series of simultaneous communication link attempts to a party'sseveral devices has succeeded first, and is thus to be continued, therest being terminated.

[0165] 5. Dispatch these data, via the Transaction Object's Script, tothe CCL [203], which creates individual software processes and/orthreads of execution for each potential communication link session basedon the aforesaid parameters. (See FIG. 25, “Script Execution” processblock.) These processes record in the CS's [2] memory and/or databasesor other storage the results of all sessions and session attempts foreach party for each transaction for later computation [L,R]. The designand processes of said communication sessions is described hereafter.

[0166] Once each party's communication session a) occurs successfullyand, if in a “Confirm” Role, obtains the required input from thecontacted party [FIG. 1, 5f; FIG. 25, H,I], such as a PIN, password, orCVV2/CVC2/CID value; b) occurs but fails to gather such required inputfrom the party [FIG. 25, J,K], or, c) fails to occur after all attemptSchedule Patterns are exhausted [FIG. 25, N,Q], the RSP [202] isnotified by the CCL [203] that all necessary sessions and contactattempts are complete [FIG. 25, S]. The RSP [202] computes a resultmessage [T] back to the RTE [1], said message being transmitted via theData Messaging Layer [201], preferably using the same format andprotocol as the received Transaction Message. Upon transmission of theresult message, the Transaction Object is removed from the CS's [2] workqueues and memory, and new Transaction Objects (if any) may then beprocessed.

[0167] Note that in a large-scale embodiment, the inventive system islikely to process a large volume of Transaction Messages and TransactionObjects concurrently, via multithreaded processing and load-balancingamong multiple processors and subsystems, and its design should not beconstrued as requiring serial processing of Transaction Messages andTransaction Objects.

[0168] Communications Control Layer and Communications Subsystems

[0169] The Communications Control Layer [203] of the preferredembodiment of the inventive system coordinates and manages the activityof the Communications Subsystems. The CCL [203], in addition to sharingthe basic elements of the CS [2] as described above, is comprised ofsoftware specific to the establishment and management of simultaneouscommunications link sessions across a plurality of media. Said softwaremay be implemented using such software frameworks and with suchapplication development tools and platforms as CallXML (an open-sourcemark-up language for creating server-based interactivetelecommunications applications) or the Adaptive CommunicationsEnvironment (an open-source software framework and library for managingsignaling, events, dynamic reconfiguration of services, and concurrentprocess synchronization for multithreaded real-time communications).

[0170] The Communications Subsystems are of three general types: 1)telephony-related for voice and audio communications, 2) Internet- anddata-related for data and text messaging, and 3) specialty data-networkrelated, for certain other types of data transfer such as EDI andSNA/RJE. The Communications Subsystems are each comprised of hardwareand software for transmitting and receiving signals to and from aspecific class of devices (terminals) over a particular communicationslink or links or communications network or networks using a specificprotocol or family of protocols. Each is further comprised of acollection of logical and physical ports, or other equivalentinterfaces, each capable of sustaining concurrent communications withone, or more where applicable, individual device(s) and/or terminal(s)across a corresponding communications link or network. (Said devices andnetworks are presumed to be external to the inventive system, but inother embodiments need not be.)

[0171] A high-level representation of a subset of the communicationslinks and media supported by a preferred embodiment of the inventivesystem is shown in FIG. 1. A complete, low-level representation of thecommunications media, interfaces, links, and potentially supporteddevices for each Communications Subsystem for an embodiment of theinventive system is presented individually from FIG. 11 to FIG. 24inclusive.

[0172] The Communications Subsystems provide a layer of abstraction tothe CCL [203], which is then able to interact with the variouscommunication media and devices of the party or parties to a transactionin terms of generic communication sessions.

[0173] The following tables relate the communications devices and mediaand the networks which support them, per the aforesaid Figures. Thefirst table identifies the media explicitly shown in FIG. 1. TABLE 1Profiled Communication Media, Related Networks, and devices per FIG. 1Communications Medium [Interface, Link] Associated Network PossibleDevice(s) Telephony Public Switched Telephone Telephone, Key system,[211, 511] Network [231] PBX with extentions, PBX with direct-dial, IVR,automated attendant [611] Electronic mail Internet Protocol networksElectronic mail software, [212, 512] (such as the Internet) [233],e-mail appliance, mobile private data networks (such e-mail device (suchas a as frame relay networks), PDA), e-mail capable public data networks(such cell phone or pager [612] as the MCI Mail network) and services(such as America Online) [232] Instant Messaging Internet Protocolnetworks Instant messaging [213, 513] (such as the Internet) [233]software, mobile IM and IM-capable services device, IM-capable cell(such as America Online) phone or pager [613] [232] Facsimile PublicSwitched Telephone Fax machine, fax server, [214, 514] Network [231] oran IP fax fax modem, virtual fax service or network (such as inboxsystem [614] by Easylink Services Corp.) Paging [215, 515] Pagingnetwork (such as by Pager, paging-capable SkyTel) [234] cell phone [216]Short Message Wireless data/telephony Mobile text messagingService/Wireless network, PCS network device, text-capable cell TextMessaging [235] phone, iMode phone [216, 516] [616] Wireless Wirelesstelephone Cellular telephone [617] Telephony network, PCS network [217,517] [235]

[0174] The following table shows media, networks, and devices arecovered indirectly in FIG. 1 under [218+], [236+], and [625+], but whichare explicitly described in FIG. 18-FIG. 24, inclusive. (Note that it isthe intent of 1 [218+], [236+] and [625+] additionally to define of theinventive system to be expanded to accommodate additional or alternativecommunications media, networks, and/or devices over time as they becomedesirable and/or available, and/or as implemented communication media,networks, and/or devices cease to be available and/or desirable.) TABLE2 Additional Profiled Communication Media, Related Networks, and Devicesper FIG. 18-FIG. 24 Communi- cations Medium [Interface, Link] AssociatedNetwork Possible Device(s) Additional or Additional or existingAdditional or existing alternative networks as they come devices as theycome media, as to support said to support said becomeadditional/alternative additional/alternative desirable/ media [FIG. 1,236+] media [FIG. 1, available 625+] [FIG. 1, 218+] IP Telephony Publicand private Internet Telephone, Key system, [FIG. 18, 218, Protocolnetworks (such as PBX or IP PBX with 518] the Internet) supporting IPextentions, PBX or IP telephony standards such PBX with direct-dial, IPas H.323 [233], and the telephone, IVR, PSTN by using an IP automatedattendant telephony gateway [231] [618] Internet Data Public and privateInternet Web server, or browser- Protocols Protocol networks (such asbased system or device including the Internet) [233] [619] HTTP/HTTPSusing HTML/ XML [FIG. 19, 219, 519] Wireless Wireless Internet ProtocolWAP-capable mobile Access networks [233] and device or cellular phoneProtocol wireless networks [620] (WAP)[FIG. supporting Internet access20, 220, 520] through a wireless-Internet gateway [235] Telex [FIG. 21,Telex network [236] Telex terminal or Telex 221, 521] mailbox service[621] File Transfer Internet Protocol networks FTP server [622] (FTP)[FIG. (such as the Internet) [233], 22, 222, 522] private data networks(such as frame relay networks) and public data services (such as AmericaOnline) [232] SNA/RJE [ SNA network [237] or an RJE capable system orFIG. 23, 223, SNA-tunneling or - device (such as an IBM 523] emulatingdata network S/390 mainframe [232] computer with IBM 3770 RJE terminalor equivalent) [623] EDI/ EDI Value-Added- EDI capable server (suchEDIFACT/ Network (such as the as by Sterling EDI-INT [FIG. SterlingCommerce VAN) Commerce, a unit of SBC 24, 224, 524] or an EDI-capable IPCorp.) network or service (such as by Internet Commerce Corp.) [238]

[0175] The CCL [203] initiates one or more concurrent, multithreadedprocesses which queue requests to obtain communication ports from one ormore of the Communications Subsystems [FIG. 11-FIG. 24] and then directthe Communications Subsystems in establishing communication with and/orto the party or parties to the transaction according to the Script andEnvironment Variables of the Transaction Object. The Script andEnvironment Variables, based on the data obtained from the Profiles,Groups, Rule Set and Communications Sequence Patterns database views[FIG. 5-FIG. 8], identify the parties and their communication devicesfor the given transaction, define a sequence for the occurrence ofcommunications with and/or to each applicable party, and specify whichcommunications links, networks, and protocols/media to use at variouspoints within said sequence.

[0176] The preferred embodiment of the inventive system provides forthree generalized sequences for contacting a party: 1) attempting toreach each device associated with that party sequentially, 2) attemptingto reach each device associated with that party in parallel, and 3)combinations thereof. Further, each device may be tried several times insuccession until contact is established with it, as defined in itsassociated Communications Sequence Pattern [FIG. 8]. The EnvironmentVariables include information for the CCL [203] and CommunicationsSubsystems to use for timing out on an individual attempt and on asequence of attempts. The CCL [203] coordinates these patterns ofcommunication attempts through to their logical conclusion.

[0177] The inventive system also provides, through a correspondingCommunications Sequence Pattern definition, a mechanism to allow a partyto initiate contact with the system within an allowed time interval,using the Environment Variable “Inbound/Outbound” [FIG. 8, 8c] inconjunction with “Attempt Timeout Value” [8 d] and “Sequence TimeoutValue” [8 e]. For this to occur, the communication address (such as atelephone number or Instant Messaging ID) of the device used by theparty must be universally and securely detectable by the appropriateCommunication Subsystem interface, such as with Automatic NumberIdentification (ANI) service for devices using the Public SwitchedTelephone Network [FIG. 11, 231] by the Telephony Interface [211].

[0178] When attempting to establish contact with a party's device, theappropriate Communications Subsystem executes a cycle of attempts, thetiming of which is defined by the values for the correspondingCommunications Sequence Pattern's fields, shown in FIG. 8, specificallythe values for First Attempt Delay [8 f], Smart Retry Flag [8 g],Maximum Number of Attempts [8 h], and Attempts Spacing [8 i]. The use ofthese party- and device-specific, user-predefined parameters to guidethe inventive system in its interaction attempts with a party providesthe invention with the advantage of a high degree of flexibility andeffectiveness in getting through to a party with a minimum ofdifficulty.

[0179] First Attempt Delay [8 f], if specified, provides for auser-defined time to elapse prior to the first contact attempt, so that,for example, the party may change a dual-use line from data mode totelephone mode for the purpose of receiving a telephony-based contact.

[0180] Smart Retry Flag [8 g], if True, indicates that theCommunications Sequence Pattern for the device shall be self-modifying(under the control of the CCL [203]) based on the outcome of eachsuccessive contact attempt. Particularly for telephony-basedcommunications, this mechanism allows the inventive system to change thetiming and quantity of future attempts based on the condition of thedevice (or network) being reached, as reported by such network to therespective Communications Subsystem interface. For example, InstantMessaging services provide a status indicator which may include valuessuch as “Active”, “Busy” or “Off line”; telephony networks respond with,among others, answer-supervision (i.e., signaling that the call has beenanswered), busy signals, or repeated rings without answer. Smart Retryprovides, for example, for increasing the frequency and number ofattempts in “busy” cases, decreasing in “off line”/“ring no answer”cases.

[0181] Maximum Number of Attempts [8 h] defines the total number ofattempts the inventive system should make to reach a device before therespective Communication Sequence Pattern is deemed exhausted. Thisvalue may be modified dynamically by the CCL [203] if the Smart RetryFlag [8 g] is set.

[0182] Attempts Spacing [8 i] defines the time intervals betweensuccessive attempts, either as a general value, or as specific valuesfor each attempt in the Sequence. This value may be modified dynamicallyby the CCL [203] if the Smart Retry Flag [8 g] is set.

[0183] As shown in FIG. 25, in the “Communication Session” processblock, an active communication session with a party's device iscomprised of the following generic cycle of functional execution ofelements of the preferred embodiment of the inventive system andcorresponding process steps:

[0184] For the first successful “Confirm” Role session and for all“Notify” sessions, as such Roles [FIG. 6, 6k; FIG. 7, 7e] and associatedScripts [FIG. 9, FIG. 26] may be defined in a given embodiment of theinvention, an associated message template, per FIG. 10, is defined inthe Environment Variables [FIG. 26: “MessageTemplate[n]”] accessible tosaid Script. In a typical embodiment of such a Script, as soon as acommunication link session is reported as open and active by thecorresponding Communications Subsystem, the Script executionprocess/thread begins composing and transmitting the various segments ofsaid message template to the communication device [FIG. 25, G],formatted according to the capabilities and limitations of thecommunication device. For example, in a telephony communication linksession, the message may be reformulated by the use of a text-to-speechprocessor [FIG. 11, 711a], and prerecorded audio may be interpolated bythe Telephony Interface [211] or related IVR processor [711 b], whereasfor an Internet HTTP session using XML, the message may be reformattedusing a referenced XML stylesheet (XLS), and text- or image-basedcomponents may be substituted for audio components of the message.

[0185] Particularly in the case of communications sessions requiringinput from the reached party, the message may consist of multiplesegments that are composed and delivered to the party's communicationdevice serially by the appropriate Communications Subsystem.

[0186] If an input is indeed required [FIG. 25, H], and the devicesupports it (per the Communication Sequence Pattern [FIG. 8, 8b:“Interactivity Flag”]), the executing Script process will preferablyprompt for and wait to receive input from the party. The form of theinput depends on the nature of the communication device and medium; fortelephony-class devices, it is typically and preferably in the form ofDTMF tones produced by touch-tone dialing or, additionally oralternatively, via voice, requiring the use of a voice recognitionprocessor [FIG. 11, 711c]; while for Internet- and data-type devices, itis typically and preferably through a return message (such as HTML <FORMMETHOD=“POST”>, e-mail SMTP reply, Instant Messaging text reply); and,for a specialty device or terminal, such as an SNA/RJE device, it istypically and preferably through a specifically formatted data exchangeparticular to the protocol being employed.

[0187] The Script may define whether the input must be validated beforeproceeding, and if so, may give the party multiple attempts to entercorrect information before abandoning the attempt. Such attempts atreceiving input may further be governed by Timeout parameters (see FIG.26, “Transaction/Communication Session Object Properties”), such that,when the indicated time has elapsed, the attempt is abandoned [FIG. 25,J]. In an out-of-time case, or in such case as a predefined number ofinput attempts is initiated over the communication link session withoutsuccessful validation, the Script delivers a timeout message segment ifso defined in the message template [K].

[0188] If input was prompted for, a corresponding Environment Variableflag is set (see FIG. 26: “PartyConfirmContact[n]”) to identify that a“Confirm” Role session has attempted to gain input required from theparty.

[0189] At the conclusion of any and all input-gathering and delivery ofmessage segments, the communication link session is terminated (by theCommunications Subsystem, and optionally by the party as well if theparty reacts more quickly than the Communications Subsystem). Theresults may be stored [L] for use by the system later on.

[0190] If the session was successfully initiated (whether or not correctinput was actually received), and was, for example, a “Confirm” Rolesession, as may have been indicated through the use of the aforesaidPartyConfirmContact[n] Environment Variable, further attempts to contactthe party in a “Confirm” Role (or equivalent, based on the embodiment ofthe inventive system) are preferably disabled for the currenttransaction.

[0191] For all non-“Confirm” devices, and if a “Confirm” Role contacthas not yet been made successfully on any “Confirm” Role device, forexample, the processes/threads executing the Communication SequencePatterns in regard to the corresponding devices continue.

[0192] After the failure of an attempt, the attempt parameters andcorresponding failure data provided by the appropriate CommunicationSubsystem are preferably logged in the system's databases or othervolatile or nonvolatile memory or storage and, if there are furtherattempts allowed, per the effective Maximum Number of Attempts setting[FIG. 8, 8h], the thread of execution for the applicable CommunicationSequence Pattern waits until the next attempt should be made, per 1) theAttempts Spacing value [8 i] corresponding to the next attempt in theSequence, and/or 2) the Smart Retry setting [8 g], as described above.This is shown in FIG. 25's “Wait per device's attempt schedule” processbox [O].

[0193] If the attempt schedule is exhausted, the executing process mayinitiate a new process with a new Communication Sequence Pattern, ifsuch additional Sequence is defined for use upon the unsuccessfulexhaustion of the current one [FIG. 8, 8j: “Action on Final Failure”].

[0194] This mechanism, an innovative advantage of the inventive system,allows the chaining of Communication Sequence Patterns to arbitrarylengths, executing until success occurs or the final Sequence in thechain of Sequences fails. It is also possible thereby (if only sometimesdesirable) to set up an endless cycle of communication attempts throughself-referencing chains of Sequences, such that the inventive systemwill attempt to establish contact with a party indefinitely, untilsuccessful. This is particularly useful in the case of a transactionwhich, by its nature and that of its parties, indicates an emergencysituation, such as an authorization transaction (non-commercial innature) regarding the entry by some party to a restricted or securedarea or system, or an extremely urgent and critical commercialtransaction requiring immediate confirmation by a party not otherwisedirectly engaged therein at the time.

[0195] It is further possible and desirable, under certain conditions,to establish an inbound Communication Sequence Pattern [FIG. 8, 8c], tobe initiated by the party, as a follow-on Sequence to an outboundSequence. For example, a wireless text message may be sent to theparty's cellular telephone, which text message includes a callbackhyperlink to an embodiment of the inventive system's TelephonyCommunications Subsystem Interface [FIG. 11, 211]. Simultaneously, aninbound Communication Sequence Pattern is established which waits forcontact from the party, similar to the underlying contact mechanismdescribed in U.S. Pat. No. 5,727,163 to Bezos. The party, by respondingto the callback hyperlink in the wireless text message, then interactswith the Telephony Interface and is joined to the executing processwhich has been waiting for his/her inbound contact.

[0196] The following Table 2 presents component technologies which maybe used by one skilled in the art to construct the communicationsinterfaces and links shown in FIG. 11-FIG. 24. TABLE 3 PossibleComponents of Communication Subsystems Embodiments Additional systemFIG. Interface Example resources Example 11 Telephony [211] Intel ®Dialogic ® Text to speech Nuance DM/V1200-4E1 processor Communications,and D/320-PCI [711a] Inc.'s Vocalizer voice cards, Intel ® CT Mediasoftware IVR [711b] Intel ® CT Media Voice Persay Inc.'s recognitionOrpheus Speaker processor Verification [711c] Platform 12 E-mail [212]Sendmail Consortium's Sendmail e-mailing software 13 Instant MessagingJabber, Inc.'s (PC-based and Jabber wireless) [213] CommunicationsPlatform 14 Fax [214] Intel ® Dialogic ® Text to fax Inso's Outside InDM/F300-E1 fax processor Server cards, Intel ® CT [714a] Media software15 Paging [215] Sendmail Consortium's Sendmail (for initiating SMTP-based alphanumeric pages) 16 Wireless Text/ Simplewire, Inc.'s SMS [216]Java SMS middleware, or Nokia Corp.'s Multimedia Email Gateway (andSMTP-to-SMS server) 17 Wireless Telephony As Telephony Text to speechNuance [217] above processor Communications, [711a] Inc.'s Vocalizer IVR[711b] Intel ® CT Media Voice Persay Inc.'s recognition Orpheus Speakerprocessor Verification [711c] Platform 18 IP Telephony [218] Intel ®Dialogic ® Text to speech Nuance DM/IP301-1E1 IP processorCommunications, Link boards for [711a] Inc.'s Vocalizer H.323 and CT IVR[711b] Intel ® CT Media Media software Voice Persay Inc.'s recognitionOrpheus Speaker processor Verification [711c] Platform 19 Web-based(HTTP, IBM Websphere HTTPS, etc. using Application Server HTML, XML,etc.) and HTTP Server; [219] optionally, IBM MQSeries Everyplace 20 WAP[220] Nokia Corp.'s Activ Server 21 Telex [221] 22 FTP [222] IBMMQSeries FTP SupportPac 23 SNA/RJE [223] IBM 377x In a non-IBM SunMicrosystems, Emulator; an system, an Inc.'s SunLink inherent functionin ASCII- SNA 3770/RJE any IBM S/390-or EBCDIC software Z-class systemconverter 24 EDI/EDIFACT/ Sterling EDI translator Sterling EDI-INT [224]Commerce's [724a] Commerce's GENTRAN: Server GENTRAN: Server and OFTPPlus

[0197] It is increasingly possible and practical for the physicalinterfaces and ports, such as those described above, to be substitutedby Internet Protocol connections to service providers and servicebureaus which accept IP-based inputs (such as SMTP-formatted e-mails)and translate and deliver such inputs to other types of device, such asfax, telex, and mobile browser-based devices. The inventive system, perits potential embodiment(s) described herein, does not purport tospecifically require any particular interface type for the statedcommunication links or communication media, nor to require that messageconversion occur within the inventive system, rather than in and by anexternal service provider's system(s). The full scope and capability ofthe inventive system and method are enumerated in the invention'sclaims.

[0198] Message Templates

[0199] As shown in FIG. 10, message templates are preferably comprisedof free-form text with embedded field substitution codes and fileinsertion codes, which may be of a form such as “$xxx$”, where ‘xxx’ isthe name of an Environment Variable (see FIG. 26), $file://yyyyy$ where‘yyyyy’ is a filepath on the Central System [2], or a Uniform ResourceLocator (URL) accessible to the Central System [2], and$=zzzz(xxx1,xxx2, . . .)$, where ‘zzzz’ is a script function name and‘xxx1’, ‘xxx2’, etc. are Environment Variables passed to the functionidentified by ‘zzzz’. In the “file” case, the contents of said file areinserted in the message template in place of the “$file:// . . . $”marker. In the other two cases, the variable or function is evaluatedand the results thereof are inserted in place of the substitutionmarker.

[0200] The use of a URL to supply some or all message contents is apowerful innovation, because it allows remote content and even remotetemplates to be included dynamically and programmatically on atransaction-by-transaction basis (that is, without requiring anyuser-initiated changes or updates to the inventive system or itsdatabases' contents whatsoever).

[0201] A message template is defined by an ID and by a language [lob],such as “English”. Therefore, a single message template may havemultiple instances across multiple languages, distinguished by thevalues in the “Language” field from record to record. A correspondingcurrency name may also be associated for use with financial content inthe message template, as per FIG. 5 [5 e].

[0202] In some circumstances, a stylesheet retrieved and referenced by aUniversal Resource Locator (URL) or Universal Resource Identifier (UDI)may be substituted for a stored message template or a message templatepassed to the central system [2] in the incoming Transaction Message.This powerful innovation allows mark-up methods of message contentdefinition and formatting definition to be applied remotely to theinventive system, on a transaction-by-transaction basis, dynamically andprogrammatically (that is, without requiring any user-initiated changesor updates to the inventive system or its databases' contentswhatsoever).

[0203] Rule, Profile, Script, Communication Sequence Pattern, andMessage Template Management

[0204] Prior to first use of the preferred embodiment of the inventivesystem, at least one entry is required in each of its various databaseviews [FIG. 5-FIG. 8] (excluding the Group view), representing a defaultRule Set, Party Profile, Communication Sequence Pattern, Action Script,and Message Template for at least one type of transaction and at leastone party from one RTE [1]. Such data entry may be performed by anoperator of the CS [2] through a means such as a web-browserbasedinterface, as shown in FIG. 1 [251: “User Web Client”], or by remotelyloading values into the database tables through a database loaderutility, or by using a programmatic interface for performing remotedatabase updates. Subsequent modifications may be performed in a likemanner.

[0205] An authorized user may log into the inventive system and, uponbeing granted access thereby, may view data and log records related tohis account and edit his/her Profile and select from among predefinedCommunication Sequence Patterns. (If a superuser, s/he may view and editthe accounts and Profiles, Rules Sets, and Communication SequencePatterns of others within his/her proscribed range of access.)

[0206] In practice, parties having a potential interest in transactionswhich may be processed by the inventive system will tend to updatedtheir own Profiles as may regard their preferred communication devices,Sequences of contact thereon, preferred language, and related Roles, forvarious transaction types which the operator or other user of theinventive system may provide to them, per the specific embodiment of theinventive system. The operator or other user of the inventive systemwill tend to manage and update all other information, particularly rule-and message-oriented information.

[0207] Although the present invention has been described in relation toparticular embodiments thereof, many other variations and modificationsand other uses will become apparent to those skilled in the art.Therefore, the present invention is not limited by the specificdisclosure herein.

What is claimed is:
 1. A system that establishes at least onecommunication with and/or to at least one party identified as engagingin or having an interest or potential interest in a transaction, usingat least one communication device associated with said at least oneparty, to notify said at least one party of said transaction and/or toauthenticate and verify said at least one party's identity andintentions regarding said transaction, comprised of: a) One or morecomputing elements which receive data regarding said transaction, saidcomputing elements having one or more central processors that executeprogrammed instructions, one or more memories for storing programmedinstructions to be executed and storing interim and/or terminal valuesrelated to the execution of said programmed instructions, andnon-volatile storage for storing other data received, obtained, orgenerated by the inventive system in the course of its operation; b) Oneor more logical and/or physical communications-related processingelements connected to or embedded within said one or more computingelements, comprised of: i. An application programming interface means;ii. At least one processor; iii. At least one memory for storing aplurality of programmed instructions to be executed and storing interimand/or terminal values related to the execution of said programmedinstructions; iv. Programmed instructions residing in said at least onememory which when executed by said at least one processor perform thesteps of initiating, maintaining, controlling, logging, and/orterminating communications over at least one communications link withand/or to at least one communications device, and v. At least onelogical and/or physical communications port enabling saidcommunications. c) A plurality of programmed instructions residing insaid one or more memories and said at least one memory, which cause saidone or more computing elements and said one or more logical and/orphysical communications-related processing elements to perform the stepsof: i. Accept incoming information about a transaction from an externalsource involved in or relating to the processing of said transaction;ii. Generate derivative information about said transaction based on anyor all of the following content found to have been included or encodedin said incoming information:
 1. Identity-related information, such asaccount numbers or other identifiers, of at least one party identifiedthereby as engaged in or having an interest or a potential interest insaid transaction;
 2. A plurality of other parameters regarding thetransaction, which may include parameters that define or guide thebehavior of said one or more computing elements and/or said one or morelogical and/or physical communications-related processing elements; iii.Communicate with and/or to at least one party identified in saidincoming information and/or in said derivative information as engaged inor having an interest or potential interest in said transaction, byestablishing or utilizing at least one communications link with and/orto at least one communication device whose communications address isassociated with said at least one party through said incominginformation and/or said derivative information; iv. Deliver at least onemessage to said at least one party using said at least onecommunications link, wherein the contents of said at least one messageare based on said incoming information and/or said derivativeinformation, and v. Generate or look up result information based on saidincoming information and/or said derivative information and/or theoutcomes of said communications.
 2. A system according to claim 1,wherein said plurality of programmed instructions residing in said oneor more memories and/or said at least one memory contain furtherinstructions causing said one or more computing elements and said one ormore logical and/or physical communications-related processing elementsto perform the further steps of prompting for and accepting at least oneauthenticating and/or verifying response from said at least one party.3. A system according to claim 2, wherein said at least onecommunications link occurs via at least one of a plurality ofcommunications media, said media comprising at least one of a landlinetelephony network such as the public switched telephone network (PSTN),a wireless telephony network, a wireless text messaging and ShortMessage Service messaging network or service, an Internet Protocol (IP)telephony network, a telex network or service, a paging network orservice, an Instant Messaging network or service, an EDI/EDIFACT/EDI-INTnetwork or service, an electronic mail network or service, an IBMSystems Network Architecture/Remote Job Entry (SNA/RJE) network orconnection, and the Internet, including via the protocols HTTP/HTTPS,UDP, FTP, and SMTP and including content formatting in accordance withgeneralized markup languages including HTML, XHTML, and XML.
 4. A systemaccording to claim 3, wherein said at least one communications linkand/or medium is different from the communications link and/or mediumused to initiate said transaction.
 5. A system according to claim 3,further adapted to incorporate additional and/or alternative types ofcommunications links without redesign or re-architecture of said system,as said additional and/or alternatives types of communications linksbecome available and desirable.
 6. A system according to claim 3,further adapted to remove and/or disable one or more enabled types ofcommunications links without redesign or re-architecture of said system,as such types of communications links cease to be available ordesirable.
 7. A system according to claim 3, further adapted toestablish simultaneous contact with a plurality of communicationsdevices on a plurality of communications addresses through a pluralityof communications links.
 8. A system according to claim 7, furtheradapted to identify the first successful communication from among aplurality of simultaneous communication attempts and select andperpetuate said first successful communication to the exclusion of theother, as-yet unsuccessful communication attempts.
 9. A system accordingto claim 3, further adapted to establish sequential communications withand/or to a plurality of communications devices on a plurality ofcommunication addresses through a plurality of communications links. 10.A system according to claim 3, wherein procedures to follow for saidtransaction, based on said incoming information and/or said derivativeinformation, are encoded as stored scripts of programming instructionsusing an executable scripting language.
 11. A system according to claim3, further adapted to block concurrent processing of multiple distincttransactions accepted by the system, when such concurrent processingwould require communicating with and/or to the same communicationsdevice or devices for more than one distinct transaction at the sametime.
 12. A system according to claim 3, further adapted to establishcommunications with and/or to a plurality of communications devices on aplurality of communication addresses through a plurality ofcommunication links according to user-defined sequences and timingpatterns of communications attempts.
 13. A system according to claim 12,further adapted to wait for an initial, predetermined, userdefined delayperiod prior to beginning said sequences and timing patterns ofcommunications attempts to a given communication device.
 14. A systemaccording to claim 12, further adapted to allow said sequences andtiming patterns to be daisy-chained into meta-sequences andmeta-patterns of arbitrary length.
 15. A system according to claim 14,further adapted to allow self-referencing chains of said sequences andtiming patterns.
 16. A system according to claim 12, wherein sequencesand patterns of communication attempts are automatically self-adjustingand self-optimizing based on the results of prior communication attemptsand on the overall progress of the processing of said transaction bysaid system.
 17. A system according to claim 12, wherein, ifcommunications with and/or to a given party is not achieved within apredefined number of attempts or a predefined time period, the sequenceand timing pattern of communications attempts for that party isterminated.
 18. A system according to claim 3, further adapted to waitfor, accept, and verify incoming communications from at least one ofplurality of communications devices over at least one of a plurality ofcommunications links.
 19. A system according to claim 18, furtheradapted to match said incoming communications to a transaction beingprocessed by the system.
 20. A system according to claim 18, furtheradapted to cease waiting for said incoming communications from a givenparty for a given transaction once a predefined time period for thatparty and transaction has elapsed.
 21. A system according to claim 3,further adapted to adapt the content of said communications and/or saidat least one message according to the capabilities and limitations ofthe communications device being communicated with and/or to.
 22. Asystem according to claim 2, further adapted to communicate distinctlywith and/or to each of said at least one party in accordance with a roleascribed to each of said at least one party in said incoming informationand/or said derivative information.
 23. A system according to claim 2,further adapted to adapt the content of said communications and/or saidat least one message in accordance with a role ascribed to each of saidat least one party in said incoming information and/or said derivativeinformation.
 24. A system according to claim 2, further adapted to adaptthe content of said communications according to a message templateand/or stored script defined or referenced in said incoming informationand/or in said derivative information.
 25. A system according to claim24, wherein said message template and/or said stored script isuserdefined.
 26. A system according to claim 25, wherein said messagetemplate and/or said stored script includes a mechanism for thesubstitution by the system of other inputs and stored values into saidat least one message.
 27. A system according to claim 26, wherein saidmechanism provides for the inclusion of additional content via aquerying or reference means into said at least one message and/or intosaid message template.
 28. A system according to claim 27, whereinformatting and additional content may be retrieved and included in orapplied to said at least one message via reference to an externalcontent and/or format source through at least one of a plurality ofmechanisms including Universal Resource Locator (URL), UniversalResource Identifier (URI), and Universal Description, Discovery andIntegration (UDDI).
 29. A system according to claim 28, wherein suchexternal content and/or format source is an XML stylesheet or XLSdocument.
 30. A system according to claim 25, wherein each of said atleast one message is composed using one of a plurality of regionalsettings including at least one of language, currency, time zone,numeric format, currency format, and date format, in accordance withpredefined preferences regarding said plurality of regional settingsassociated with the party who is to receive that message.
 31. A systemaccording to claim 2, wherein said derivative information includesinformation retrieved via a querying or referencing means from anexternal information source or service.
 32. A system according to claim2, wherein said derivative information includes predeterminedinformation identifying additional parties having an interest orpotential interest in a given transaction, who were not otherwiseidentified or referenced in said incoming information.
 33. A systemaccording to claim 2, further adapted to communicate differently withand/or to each of said at least one party, based upon said incominginformation and/or said derivative information, which incoming and/orderivative information includes or encodes at least one role ascribed toeach of said at least one party.
 34. A system according to claim 33,wherein said at least one role is user-defined.
 35. A system accordingto claim 33, wherein each of said at least one party may have multipleroles in a given transaction.
 36. A system according to claim 34,wherein said at least one role comprises a plurality of roles includingat least one of “Confirm” when the party is to confirm his/her identityand intentions regarding the transaction; “Notify” when the party is toreceive notification of the transaction only; and “Present” when anydata associated with the party in the incoming transaction-describingdata are only to be verified against stored, predefined informationabout the party without any communications occurring with and/or to saidparty.
 37. A system according to claim 2, further adapted to prompt forand obtain from said at least one party during said communications atleast one response comprising at least one data value which confirmssaid at least one party's identity and additionally or alternativelysaid at least one party's intention to approve and conclude thetransaction.
 38. A system according to claim 37, wherein said at leastone data value is received via at least one of a plurality of inputmeans, based on the capabilities of the communications device beingused, said input means comprising at least one of dialing or pressing ortouching of digits including the use or generation of DTMF tones,vocalizations, data entry via a computing device, data entry via aterminal, data entry via a web browser, data entry via a WAP browser,facsimile transmission interpretable by a character-recognizing computerprogram, EDI/EDIFACT/EDI-INT transmission, electronic mail transmission,Instant Messaging transmission, and Internet transmissions wherein themessage content is formatted in accordance with generalized markuplanguages including HTML, XHTML, and XML.
 39. A system according toclaim 37, wherein said at least one input includes at least one of aplurality of data values, said data values comprising at least one of aPIN code; a Social Security Number or portion thereof; a government ortax ID number or portion thereof; a telephone number; a CVC2, CVV2, orCID credit card or debit card code; a user-defined ID number; a serialnumber; a user-defined password, and a user-defined security word (suchas a mother's maiden name) or portion thereof.
 40. A system according toclaim 2, wherein information regarding any given party and his/herassociated communications devices, communications addresses, roles, andcommunications preferences is organized and stored in a user-definedprofile.
 41. A system according to claim 40, wherein such profiles maybe added or modified singly or in bulk over the Internet or an intranetor extranet using a web-browser.
 42. A system according to claim 40,wherein such profiles may be added or modified singly or in bulk overthe Internet or an intranet or extranet using an application programminginterface means.
 43. A system according to claim 2, wherein rules whichgovern the system's behavior for a given transaction type and a givenparty or group of parties are organized and stored in a user-definedrules profile.
 44. A system according to claim 43, wherein such rulesmay be added to or modified singly or in bulk over the Internet or anintranet or extranet using a web-browser.
 45. A system according toclaim 43, wherein such rules may be added to or modified singly or inbulk over the Internet or an intranet or extranet using an applicationprogramming interface means.
 46. A system according to claim 2, whereinsaid external source for said incoming information is an externalcomputer system or computing device utilizing a communications link. 47.A system according to claim 46, wherein said communications linkutilizes the Internet Protocol (IP).to
 48. A system according to claim46, wherein said communications link utilizes middleware having amessage queuing capability.
 49. A system according to claim 46, whereinsaid external source may specify in the incoming information additionalparameters to be used additionally or alternatively to any internallypredetermined parameters and/or to any of said derivative information,so as to cause the inventive system to adapt its processing of saidincoming information and/or its communications in accordance with saidadditional parameters.
 50. A system according to claim 46, furthercomprising a normalization module, wherein said system receives saidincoming information said external source and said normalization modulenormalizes said incoming information into a standardized format tocreate normalized information, and wherein said system processes saidnormalized data in lieu of said incoming information.
 51. A systemaccording to claim 2, further adapted to communicate said resultinformation back to said external source.
 52. A system according toclaim 51, further adapted to communicate said result informationadditionally or alternatively to an external second system or device.53. A system according to claim 52, wherein said external second systemor device is identified by a user-defined parameter.
 54. A systemaccording to claim 52, wherein said external second system or device isidentified or encoded in said incoming information and/or identified insaid derivative information.
 55. A system according to claim 46, saidsystem monitoring a plurality of external sources involved in to theprocessing of transactions via a plurality of communications links, eachexternal source having its own identification and/or authenticationcode, and said system further comprising at least one memory in whichsaid identification codes and/or authentication codes are stored, and acomparator comprising further programmed instructions executed by saidsystem, wherein said identification codes and/or authentication codes assupplied by said external sources are checked by said comparator againstsaid stored identification codes and/or authentication codes stored insaid at least one memory to validate the origin of any incominginformation received from said external sources and thereby to rejectany incoming information wherein the identification code and/orauthentication code is not valid, or is missing.
 56. A system accordingto claim 3, further adapted to retain in said one or more memoriesand/or said non-volatile storage a transaction log, comprising saidincoming information and any said derivative information, and anyinterim and final result information from any or all steps performed bysaid one or more computing elements and/or said one or more logicaland/or physical communications-related processing elements.
 57. A systemaccording to claim 56, further adapted to present said transaction logand/or information based on and/or derived from said transaction loglocally or remotely via a user interface, such as a web-browser.
 58. Asystem according to claim 56, further adapted to communicate saidtransaction log and/or information based on and/or derived from saidtransaction log via an application programming interface means.
 59. Ascripting language for encoding a script which, upon its execution bysaid one or more computing elements executing said programmedinstructions, controls and/or amends the steps taken by said system,based on a) the contents of said incoming information and/or saidderivative information, b) subsequent events and occurrences resultingfrom and/or relating to the execution of said scripts, c) changes ofstate of said system during the execution of said script, and d) theprogress and results of said communications with said at least oneparty, comprising: executable instructions for composing, formatting,delivering, and managing messages and communications with and/or to saidat least one party, environment variables and objects having objectproperties, which variables and properties being set case-by-case bysaid one or more computing elements and/or said one or more logicaland/or physical communications-related processing elements for a giventransaction based on said incoming information and/or said derivativeinformation, a lookup capability for retrieval of additional oralternative information based on said incoming information and/or saidderivative information, and a branching and control capability fordetermining the sequence and choice of steps to perform, based oninterim and final results, progress indicators, system states, andevents which occur during the execution of said script.
 60. A method forverifying, authenticating, and providing notification of a transaction,such as a commercial or financial transaction, with and/or to at leastone party identified as engaging in said transaction and/or having apotential interest in said transaction or type of transaction,comprising the steps of: a) Obtaining or accepting primary informationregarding a transaction from an external source; b) Generating secondaryinformation regarding said transaction based on any or all of thefollowing primary information available in regard to said transaction:i. Identity-related information, such as account numbers or otheridentifiers, of at least one party identified thereby as engaged in orhaving an interest or a potential interest in said transaction, and ii.A plurality of other parameters and/or characteristics of thetransaction, c) Communicating with and/or to at least one partyidentified in said primary information and/or in said secondaryinformation as engaged in or having an interest or potential interest insaid transaction, by establishing or utilizing at least onecommunications link with and/or to at least one communication devicewhose communications address is associated with said at least one partythrough said primary information and/or said secondary information; d)Delivering at least one message to said at least one party using said atleast one communications link, wherein the contents of said at least onemessage are based on said primary information and/or said secondaryinformation, and e) Generating or looking up result information based onsaid primary information and/or said secondary information and/or theoutcomes of said communications.
 61. A method according to claim 60,further comprising the steps of prompting for and accepting at least oneauthenticating and/or verifying response from at least one of said atleast one party.
 62. A method according to claim 60, further comprisingthe steps of prompting for and accepting at least one authenticatingand/or verifying response from either none or at least one of said atleast one party based on said primary information and/or said secondaryinformation.
 63. A method according to claim 62, wherein step (c)further comprises the step of establishing or utilizing at least onecommunications link via at least one of a plurality of communicationsmedia, said media comprising at least one of a landline telephonynetwork such as the public switched telephone network (PSTN), a wirelesstelephony network, a wireless text messaging and Short Message Servicemessaging network or service, an Internet Protocol (IP) telephonynetwork, a telex network or service, a paging network or service, anInstant Messaging network or service, an EDI/EDIFACT/EDI-INT network orservice, an electronic mail network or service, an IBM Systems NetworkArchitecture/Remote Job Entry (SNA/RJE) network or connection, and theInternet, including via the protocols HTTP/HTTPS, UDP, FTP, and SMTP andincluding content formatting in accordance with generalized markuplanguages including HTML, XHTML, and XML.
 64. A method according toclaim 63, wherein said at least one communications link and/or medium isdifferent from the communications link and/or medium used to initiatesaid transaction.
 65. A method according to claim 63, wherein step (c)further comprises the step of establishing communications simultaneouslywith and/or to a plurality of communications devices on a plurality ofcommunications addresses through a plurality of communications links.66. A method according to claim 65, wherein step (c) further comprisesthe step of identifying the first successful communication from among aplurality of simultaneous communication attempts and select andperpetuate said first successful communication to the exclusion of theother, as-yet unsuccessful communication attempts.
 67. A methodaccording to claim 63, wherein step (c) further comprises the step ofestablishing communications sequentially with and/or to a plurality ofcommunications devices on a plurality of communication addresses througha plurality of communications links.
 68. A computer-implemented methodaccording to claim 63, wherein procedures to follow for saidtransaction, based on said primary information and/or said secondaryinformation, are encoded as stored scripts of programming instructionsusing an executable scripting language.
 69. A computer-implementedmethod according to claim 63, further comprising the step of blockingconcurrent processing of multiple distinct transactions accepted by thesystem, when such concurrent processing would require communicating withand/or to the same communications device or devices for more than onedistinct transaction at the same time.
 70. A method according to claim63, wherein step (c) further comprises the step of establishingcommunications with and/or to a plurality of communications devices on aplurality of communication addresses through a plurality ofcommunication links according to at least one sequence and timingpattern of communications attempts.
 71. A method according to claim 70,wherein step (c) further comprises the step of waiting for an initial,predetermined delay period prior to beginning said at least one sequenceand timing pattern of communications attempts to a given communicationdevice.
 72. A method according to claim 70, wherein step (c) furthercomprises the step of concatenating said at least one sequence andtiming pattern into meta-sequences and meta-patterns of arbitrarylength.
 73. A method according to claim 72, wherein said meta-sequencesand meta-patterns include self-references by and among said at least onesequence and timing pattern making up said metasequences andmeta-patterns.
 74. A method according to claim 70, wherein step (c)further comprises the step of altering said at least one sequence andtiming pattern of communication attempts based on the results of priorcommunication attempts and on the overall progress of the processing ofsaid transaction by said system.
 75. A method according to claim 70,wherein step (c) further comprises the step of terminating the sequenceand timing pattern of communications attempts for a given party ifcommunications with and/or to that party is not achieved within apredefined number of attempts or a predefined time period.
 76. A methodaccording to claim 63, further comprising the step of waiting for,accepting, and verifying incoming communications from at least one ofplurality of communications devices over at least one of a plurality ofcommunications links.
 77. A method according to claim 76, furthercomprising the step of matching said incoming communications to one of aplurality of concurrent transactions.
 78. A method according to claim76, further comprising the step of ceasing to wait for said incomingcommunications from a given party for a given transaction once apredefined time period for that party and transaction has elapsed.
 79. Amethod according to claim 63, further comprising the step of alteringthe content of said communications and/or said at least one messageaccording to the capabilities and limitations of the communicationsdevice being communicated with and/or to.
 80. A method according toclaim 62, further comprising the step of ascribing with a role to eachof said at least one party based on said primary information and/or saidsecondary information.
 81. A method according to claim 80, wherein step(c) further comprises the step of communicating in a distinct mannerwith and/or to each of said at least one party in accordance with therole ascribed to that party.
 82. A method according to claim 80, whereinstep (c) further comprises the step of altering the content of each ofsaid communications and/or each of said at least one message inaccordance with the role ascribed to each corresponding party.
 83. Acomputer-implemented method according to claim 62, wherein step (c)further comprises the step of altering the content of saidcommunications according to a message template and/or stored script. 84.A computer-implemented method according to claim 83, wherein step (c)further comprises the step of substituting of other inputs and storedvalues into said at least one message.
 85. A computer-implemented methodaccording to claim 84, wherein step (c) further comprises the step ofincluding additional content via a querying or reference means into saidat least one message and/or into said message template.
 86. Acomputer-implemented method according to claim 85, wherein step (c)further comprises the step of retrieving and including or applyingformatting and additional content in or to said at least one message viareference to an external content and/or format source through at leastone of a plurality of mechanisms including Universal Resource Locator(URL), Universal Resource Identifier (URI), and Universal Description,Discovery and Integration (UDDI).
 87. A computer-implemented methodaccording to claim 86, wherein such external content and/or formatsource is an XML stylesheet or XLS document.
 88. A method according toclaim claim 83, wherein step (c) further comprises the step of composingsaid at least one message using one of a plurality of regional settingsincluding at least one of language, currency, time zone, numeric format,currency format, and date format, in accordance with predeterminedpreferences regarding said plurality of regional settings associatedwith the party who is to receive that message.
 89. A method according toclaim 62, wherein step (b) further comprises the step of retrievinginformation via a querying or referencing means from an externalinformation source or service based on said primary information and/orsaid secondary information.
 90. A method according to claim 62, whereinsaid secondary information includes predetermined informationidentifying additional parties having an interest or potential interestin a given transaction, who were not otherwise identified or referencedin said primary information.
 91. A method according to claim 62, furthercomprising the step of communicating differently with and/or to each ofsaid at least one party, based upon said primary information and/or saidsecondary information, which primary and/or secondary informationincludes at least one role ascribed to each of said at least one party.92. A method according to claim 91, wherein each of said at least oneparty may have multiple roles in a given transaction.
 93. A methodaccording to claim 62, further comprising the step of prompting for andobtaining from said at least one party during said communications atleast one response comprising at least one data value which confirmssaid at least one party's identity and additionally or alternativelysaid at least one party's intention to approve and conclude thetransaction.
 94. A method according to claim 93, wherein said at leastone data value is received via at least one of a plurality of inputmeans, based on the capabilities of the communications device beingused, said input means comprising at least one of dialing or pressing ortouching of digits including the use or generation of DTMF tones,vocalizations, data entry via a computing device, data entry via aterminal, data entry via a web browser, data entry via a WAP browser,facsimile transmission interpretable by a character-recognizing computerprogram, EDI/EDIFACT/EDI-INT transmission, electronic mail transmission,Instant Messaging transmission, and Internet transmissions wherein themessage content is formatted in accordance with generalized markuplanguages including HTML, XHTML, and XML.
 95. A method according toclaim 93, wherein said at least one response includes at least one of aplurality of data values, said data values comprising at least one of aPIN code; a Social Security Number or portion thereof; a government ortax ID number or portion thereof; a telephone number; a CVC2, CVV2, orCID credit card or debit card code; a user-defined ID number; a serialnumber; a user-defined password, and a user-defined security word (suchas a mother's maiden name) or portion thereof.
 96. A method according toclaim 62, further comprising the steps of organizing and storinginformation regarding any given party and his/her associatedcommunications devices, communications addresses, roles, andcommunications preferences in a user-defined profile.
 97. Acomputer-implemented method according to claim 96, further comprisingthe steps of adding and modifying said profiles singly or in bulk overthe Internet or an intranet or extranet using a web-browser.
 98. Acomputer-implemented method according to claim 96, further comprisingthe steps of adding and modifying said profiles singly or in bulk overthe Internet or an intranet or extranet using an application programminginterface means.
 99. A computer-implemented method according to claim62, further comprising the steps of organizing and storing rules whichgovern the behavior of a system implementing said method for a giventransaction type and a given party or group of parties in a user-definedrules profile.
 100. A computer-implemented method according to claim 99,further comprising the steps of adding and modifying said rules profilessingly or in bulk over the Internet or an intranet or extranet using aweb-browser.
 101. A computer-implemented method according to claim 99,further comprising the steps of adding and modifying said rules profilessingly or in bulk over the Internet or an intranet or extranet using anapplication programming interface means.
 102. A computer-implementedmethod according to claim 62, wherein said external source for saidprimary information is an external computer system or computing deviceutilizing a communications link.
 103. A computer-implemented methodaccording to claim 102, further comprising the step of using additionalparameters the external source may specify in the primary information soas to alter said method in accordance with said additional parameters.104. A computer-implemented method according to claim 102, furthercomprising the step of normalizing said primary information into astandardized format to create normalized information.
 105. Acomputer-implemented method according to claim 62, further comprisingthe step of communicating said result information back to said externalsource.
 106. A computer-implemented method according to claim 105,further comprising the step of communicating said result informationadditionally or alternatively to a user-defined second external source.107. A computer-implemented method according to claim 62, furthercomprising the steps of monitoring a plurality of external sourcesinvolved in the processing of transactions via a plurality ofcommunications links, each external source having its own identificationand/or authentication code, and checking said identification codesand/or authentication codes as supplied by said external sources againsta predetermined list of at least one identification code and/orauthentication code to validate the origin of any primary informationreceived from said external sources and thereby to reject any primaryinformation wherein the identification code and/or authentication codeis not valid, or is missing.
 108. A computer-implemented methodaccording to claim 63, further comprising the step of generating atransaction log, comprising said primary information and any saidsecondary information, and any interim and final result information fromany or all steps performed in accordance with said method.
 109. Acomputer-implemented method according to claim 108, further comprisingthe step of presenting said transaction log and/or information based onand/or derived from said transaction log locally or remotely via a userinterface, such as a web-browser.
 110. A computer-implemented methodaccording to claim 108, further comprising the step of communicatingsaid transaction log and/or information based on and/or derived fromsaid transaction log via an application programming interface means.